Elsevier required licence: © <2016>. This manuscript version is made available under the  CC‐BY‐NC‐ND 4.0 license http://creativecommons.org/licenses/by‐nc‐nd/4.0/    A Disaster Management Knowledge Repository (DMKR) and Sharing System Siti Hajar Othman, Ghassan Beydoun Abstract. Disaster Management (DM) is collaborative and complex. Roles involved in DM processes often cut across many organizational boundaries and are dynamic. Knowledge involved is enormous and diverse. It includes information related to varieties of disasters, roles, plans and operations. Many practices may also vary across different regions and authorities. Structuring, storing and reusing DM knowledge is the challenge tackled in this paper. The paper presents a Metamodel-based Disaster Management Knowledge Repository (DMKR) tool, DMKR1.0, to facilitate collaboration and DM knowledge sharing. The knowledge representation that underpins the repository structure is a disaster management modeling language that makes statements about what can be expressed in various DM models. Using the tailored DM language, the tool developed offers a flexible structure to allow the storage and retrieval not only of observed and measured data, but also interpretative and inferred information of the disaster management knowledge. The paper describes the development, functionality and implementation of DMKR. The validation of DMKR illustrates how users can easily instantiate DM models to communicate and generalize their knowledge for the benefit of sharing it within their community. Keywords: Knowledge Sharing; Decision Making; Disaster Management; Metamodels A Disaster Management Knowledge Repository (DMKR) and Sharing System Siti Hajar Othman, Ghassan Beydoun Abstract. Disaster Management (DM) is collaborative and complex. Roles involved in DM processes often cut across many organizational boundaries and are dynamic. Knowledge involved is enormous and diverse. It includes information related to varieties of disasters, roles, plans and operations. Many practices may also vary across different regions and authorities. Structuring, storing and reusing DM knowledge is the challenge tackled in this paper. The paper presents a Metamodel-based Disaster Management Knowledge Repository (DMKR) tool, DMKR1.0, to facilitate collaboration and DM knowledge sharing. The knowledge representation that underpins the repository structure is a disaster management modeling language that makes statements about what can be expressed in various DM models. Using the tailored DM language, the tool developed offers a flexible structure to allow the storage and retrieval not only of observed and measured data, but also interpretative and inferred information of the disaster management knowledge. The paper describes the development, functionality and implementation of DMKR. The validation of DMKR illustrates how users can easily instantiate DM models to communicate and generalize their knowledge for the benefit of sharing it within their community. 1.0 Introduction Disaster Management (DM) processes involve many interacting elements e.g.: people, authority, emergency teams, resources, procedures, uncertain environmental situations and many more. Modeling coordination of DM activities is tremendously hard and complex. DM activities often extend across various government sectors, non-governmental organizations/industry, from international levels down to state or region levels and may also include individual people and various facets of society. It is often unclear what are the exact tasks and responsibilities before, during or after a disaster strikes. The complexity of DM and the failures of DM agencies can be observed in many recent examples, e.g. the management of the Swine-Flu (H1N1) pandemic hitting Australian shores in large numbers through cruise ships in 2009 (Larcombe, Moloney et al. 2009), or the devastating communication failures in the Victorian bushfires in Victoria in 2008 (Cordner, Woodford et al. 2011). Observed failures often surface as the required expertise not being available in a timely manner or a systemic inability to timely recognize and identify the required expertise. Reusing expertise is overlooked as it is often perceived as too specific to kinds of events such as floods, bushfires, tsunamis, pandemics or earthquakes. This research advocates the use of a middle knowledge layer to enable DM practitioners to discern disaster dependent and disaster-independent features in the challenges that they face. For this purpose, the Metamodel-based Disaster Management Knowledge Repository (DMKR) is constructed. The structure of the repository is an essential factor in obtaining good retrieval results for knowledge retrieval system (Shiva and Shala 2007). DMKR structure follows a tailored DM metamodel that recently appeared in (Othman, Beydoun et al. 2014). DMKR facilitates knowledge reuse and timely identification of required DM knowledge sources. It allows a unified access to various DM experiences and offers a common DM description language. The work advocates that combining expertise used in various disasters will enable the best approach in managing a new disaster. It provides the following benefits:  Facilitating communication among different disaster emergency users;  Simplifying the teaching of new DM approaches through a set of semantic rules;  Providing guidelines for creating DM models which can cover specific phases of DM (e.g: Response Phase Earthquake Emergency Response Model, Mitigation Phase Bushfire Risk Reduction Model);  Highlighting scope for improvement in a DM practice through validation against other existing metamodels in DM field. We developed and validated a DM language as a middle layer of knowledge in the form of a disaster-independent metamodel to unify knowledge from different disaster experiences in (Othman, Beydoun et al 2014). This required tuning the metamodelling process to DM to ensure that appropriate knowledge sources (candidate models) are identified and used as input to the process. The resulting language, DMM, was theoretically validated showing how 89 DM models from the literature can be generated from the DMM (Othman, Beydoun et al 2014). In this paper, we deploy the language by demonstrating a viable and a unifying DM knowledge repository. This paper develops an actual knowledge sharing system, the DMKR system which stores DM solution modelling components and guides users on how to reconstruct solutions as new contexts arise. To store DM knowledge as reusable modelling components, DMKR has a metamodel driven interface to guide DM experts to articulate their knowledge appropriately. To illustrate the expressive power of the system, a number of case studies to describe real disaster situations are used in the DMKR implementation. Besides constructing DM solution models based for specific disaster problems presented to the system, DM stakeholders are also provided with the solutions from a range of disaster categories (e.g.: earthquake, landslide, nuclear meltdown and etc.). This enables mixing and matching solutions across different disasters. Typical, users of DMKR can be disaster managers (local, state or federal), monitoring personnel, coordinators, aid agencies or even researchers who may wish to study the domain. The rest of this paper is organized as follows: Section 2 describes the DM model driven background and related work that underpin the conceptual foundation of this paper. Section 3 describes the development and the architecture of a model driven DM system. Section 4 demonstrates the usefulness of the system implementing it and illustrating in real-world disaster problems. Specifically, a bushfire disaster exemplar is used to illustrate the knowledge capture and reuse facilitated by the system. Finally, Section 5 concludes with recommendations for future research. 2.0 Background and Related Work A model is an abstract representation of a real world domain typically used to manage complexity (Levendovszky, Rumpe et al. 2010). It generally consists of a collection of two elements: concepts and relationships. Concepts characterize domain entities and relationships characterize links between them (Trabelsi, Atitallah et al. 2011). A model explicitly expresses the structure, behaviour and other properties in a domain and ideally has a causal connection to the real world (Aßmann, Zschaler et al. 2006). Our approach for DM knowledge sharing can be said to be model-driven. It is inspired by model driven systems development (Colin, Thomas et al. 2003, Stahl, Voelter et al. 2005). Instead of requiring software developers to detail how a system is implemented, in a model-driven approach software models specify what the functionality and the architecture of the system to be used are (Colin, Thomas et al. 2003) via the use of software models developed in a specific language. With syntactically correct models, using only allowed symbols and conforming to rules, the modelling language facilitates sharing of the outcome of the modelling process. Developers are able to abstract and share knowledge using models as starting points. To formally describe the semantics underpining a formal modelling language, a metamodel is required, without which semantics of domain models can be ambiguous (2000). Applying a model driven approach to share DM knowledge has the added benefit of also making knowledge accessible to non-technical specialists and newcomers to DM. Similar to model-driven software development, this also requires a DM modelling language to specify all elements with which any model can be described. Model transformations can then enable precise and timely knowledge sharing communication across the various phases of the process (Trabelsi, Atitallah et al. 2011). Similarly, in DM, these are also required to enable the unified access to various DM knowledge models and to also communicate the knowledge across different disasters and DM activities. The metamodel we use in this paper to specify DM modelling constructs is DMM. This is a DMM specific metamodel which we synthesized and validated created in (Othman, Beydoun et al. 2014). DMM has four sets of concept classes: the Mitigation (shown by Figure 2), Preparedness (Figure 3), Response (Figure 4) and Recovery (Figure 5) class of concepts. Each set represent a corresponding DM phase. This clearly describes the DM domain to its users. The relationship between the metamodel and domain models are described through model transformations (Vytautas Stuikys 2010) which convert one model to another model (OMG 2003). In this work, we deploy the transformations prescribed in the metamodelling framework of MOF, the standard for software metamodelling offered by a OMG (2002). MOF is essentially a meta-metamodel that defines a common way for capturing the diversity of modelling standards and interchange constructs that are used in model driven software engineering. In (Cook 2004), the MOF is defined as a framework designed for defining modelling languages. MOF is based on a hierarchical architecture of four meta-layers as illustrated in Figure 1, MOF is primarily about defining information models for metadata. It uses an object-modelling framework that is essentially a subset of the UML core. The main four modelling concepts in MOF are classes, association, data types and package. The main advantages of OMG standard are wide acceptance, coverage of many domains and cohesion among the standard (M. Picka 2004). MOF has four layers, M0, M1, M2 and M3. It has different views on modelling at different layers of details. It is strictly hierarchical. Concepts at any given layer (below M3) belong to a concept from the layer above. Any concept in any given layer (above M0) can be instantiated at the layer below. M3-Level is reserved for Meta-metamodel element, comprised of the description of the structure and semantics of meta-meta data. M2-Level is for the metamodel layer (instance of meta-metamodel), comprised of the descriptions of the structure and semantics of metadata. M1-Level is designed for the model layer (instance of metamodel), comprised of the metadata that describe data in the information layer. The lowest level, M0, is dedicated for user models (instance of model and also called as information layer). In this paper, M0-Level will cover the data that a disaster model describes at M1. Figure 1 The derivation of various DM solution models in three MOF modelling layers Figure 2 The DMM - Mitigation-phase class of concepts The system introduced in this paper, DMKR 1.0, represents how all the components associated the DMM are operationalised. It is inspired by method engineering, where a metamodel is used to index a software development methodology as required by a software process model (Firesmith 2006). The design of DMKR and the theories underlying it are described in the next section. Figure 3 The DMM - Preparedness-phase class of concepts Figure 4 The DMM - Response-phase class of concepts 3.0 The Disaster Management Knowledge Repository System (DMKR) This section describes the architecture of the knowledge repository, DMKR 1.0. This repository utilises DMM as a representational infrastructure to store and structure complex DM knowledge and processes. DMKR integrates the metamodel with retrieval and modeling support components. It has a model driven interface to ensure that users can easily access and reuse the stored knowledge (see Figure 6). The stored knowledge can be reused to develop varying DM solutions as DM contexts vary. It has a modelling tool to develop variety kinds of new DM models based on past DM problems and knowledge retrieved. New DM models can be derived through operationalisations of vertical model transformations from DMM. The transformations used are: Instantiation (to instantiate a single Concept), and Conformance (to instantiate a Model holistically from a number of concepts). For example, an Emergency Response Model (an M1-Model) is a model conformance from the DMM (Figure 1). At this level, M1-Fragment is used to represent DM models. An M1 solution derived from DMM can in turn derive various models of real-world disasters at the M0-level e.g.: response after a nuclear meltdown, rescue and search after an earthquake, flood rescue model etc. This M0-Level is the DM User Model and represents real-world DM activities sought by DM users. Concepts at this level are represented through M0-Fragment. The combination of all M0-Fragments would form the DM solution model (M0-User Model) from the system. Figure 5 The DMM - Recovery-phase class of concepts 3.1 DMKR Architecture DMKR design has three components (see Figure 7): (a) Module A – DMM and its tools component: This contains four sub-components: Consistency Checker Module, Metamodel Formulation Module, Modelling Constructor Module, DMM Concepts Database. Each of these will be detailed in Section 3.3. (b) Module B – The DM knowledge base (The “DM Knowledge Repository”): The repository schema of this database follows the structure of its metamodel. It stores a collection of emergency organisation and coordination activities executed by different agencies. (c) Module C – The retrieval module (The “DM Retrieval”): This module functions to assist in deriving the best DM model solution according to the disaster in hand. The DMKR is built using a relational database management system (RDBMS). The usage of RDBMSs in metamodelling applications is common, e.g. in geosciences (Viswanathan and Schneider 2010), for geographic data (Shanzhen and Yuntao 2011) and web-based interface components (Panesar-Walawege, Knutsen et al. 2011). A collection of relational database tables is created to manage the variety of modelling tools element in DMKR. These include: Model Fragments (M2-Fragment, M1-Fragment, and M0-Fragment); Model Database (M2-DMM, M1- Model and M0-User Model); Concept and Class elements (Terminology, Notations); DM Knowledge (Data for Model Fragments); User Information (DM Real-user); and Disaster information (Type of disaster). Figure 6 The main page of the DMKR system Figure 7 The DMKR System Architecture 3.2 Knowledge Representation in DMKR In DMKR, modelling structures to support specific DM activities and related past experiences to these activities are available side by side. The experiences underpin the DM knowledge stored as Model Fragments. In DMKR, knowledge is populated in a structured knowledge storage unit known as Model Fragments - the building blocks of reuse. These reusable knowledge units can be mixed and matched as DM context demands. The use of modelling fragments is adapted from method engineering field where a fragment describes a cohesive method component (Firesmith 2006). DMM itself is expressed as a collection of M2-Fragments making statements about what can be expressed in valid DM models. Each concept in DMM has its own M2-Fragment. In this research, a fragment consists of DM operations and modelling structures that are prerequisites for the applicability of the operations. Following the MOF metamodelling framework, a model fragment is available at three levels of abstractions (Table 1): The M2-Metamodel Level, the M1-DM Model, and the M0-DM User Model. The M2-Fragment is used to represent fragment for concept in the M2-Metamodel (DMM), the M1-Fragment is used to represent an instance of concept in the M1-DM Model, and the M0-Fragment is used to represent information of the instance of concept in the M0-DM User Model. When an M1-Model is developed, DM knowledge of every single unit fragments of the model can later be retrieved and reused. The user is guided to user identify relations between unit fragments and DM knowledge. This offers fast and precise knowledge derivation. Object oriented inheritance links these fragments across the three levels of MOF. For DMM, when a model fragment is indexed by the metamodel, the actual operational DM knowledge will need to be generated as M0-Fragments. To enable effective usage of concepts to create combination of concepts at the M1-Level and M0-Level, DMKR users are given explanations about domain concepts in the metamodel level. These explanations provide examples and more details of usage. Table 1 Representation of DMM Concept in MOF modelling paradigm Model Level Level Name Description Elements M2 DMM Metamodel  Defines the language for specifying a DM model  Consists of MetaClasses, MetaAttributes, MetaOperations, MetaRelationships of DMM concepts M2-Fragment (Metamodel fragments) - Contains DMMClass (e.g.: Concept: “Evacuation”, “Aid”, “EmergencyPlan”, “Warning”) M1 DM Model Instance of DMM Metamodel  Models a specific information of DM problems ( e.g.: Emergency Preparedness Model – all the required components for this model are defined in DMM) M1-Fragment (Data Model Fragments) - Contains DMMObject (e.g.: a) setupEvacuationCentre (from “Evacuation”), b) refugeeShelterDonation (from “Aid” concept), c) identifyDamageCost (from “DamageAssessment” concept), d) disseminateAlertWarning (from “Warning” concept) M0 DM User Model Instance of DM Model  Models user’s real world data  DM Model represents a real DM M0-Fragment (User Model Fragments) - Contains DMMInstance of Real World Data (e.g.: Data on Evacuation during Flood disaster in Brisbane, Aid distribution during Japan Tsunami) The object-oriented paradigm is used to design and implement Model Fragment in DMKR. Every DMM concept is represented as Class, DMMClass. DM Concept::= DMMClass (Note: Symbol ::= is an equivalent). Each DMMClass has the following fields: name, ID, terminology, attribute, operations, and relationships. That is: DMMClass::= where:  DMMClassName represents a DM concept name  DMMClassTerminology represents a DM concept definition  DMMClassAttribute represent a DM requirement  DMMClassOperation represent a DM task  DMMClassRelationship represents the relationship with other concept/s  DMMClassID is a unique identifier for the concept Each DMM concept is represented as a DMMClass which has its own M2-Fragment, a unit fragment. The coupling between the DM operations and the contextual knowledge required for their applicability, in unit fragments (specific for this research, a Model Fragment is used to represent this unit fragments). Each concept will have its own concept’s task, requirement, plan, responsible user etc. These are refined down the MOF hierarchy through the corresponding unit fragments. An example of this is shown in Table 2 giving an example of a DMMClass concept, Evacuation, a Preparedness-phase concept and how it becomes refined from M2 to M0 according to DM context. Table 2 The DMMClass of Evacuation concept Class EVACUATION ClassID BP07 Definition: An organised, phased and supervised withdrawal, dispersal or removal of civilians from dangerous or potentially dangerous areas, and their reception and care in safe areas. Relations PreparednessPlan (BP01) Relation type: Association, Relation name: “Follows” Warning (BP05) Relation type: Association, Relation name: “Activates” A tt ri b u te s evacuationName: The name of the process (e.g.: Queensland Flood Evacuation). evacuationRoad: The network of roads where evacuees will travel to reach a safe evacuation destination. evacuationCentres: The safe destination for people who live in disaster risk areas as a temporary refuge. evacuationTransport: The transportation facilities that have a capacity and need for resources (e.g.: fuel) to travel (e.g.: ambulance, helicopter, fire engine). evacuationAlertProcedure: Communication of public warning. evacuationAuthority: Leaders who have the authority to order evacuations. evacuationExercise: A program to practice the need to evacuate under certain circumstances and play specific actions to be taken when a real disaster happens. evacuationServiceTeam: Availability of emergency services facilities and personnel (e.g.: personnel and equipment for search and rescue, hospital and medical services). hazardZone: The zone areas where the disaster took place which has one or more locations (e.g.: North Queensland during Cyclone Yasi 2010). locationAtRisk: The location where people at risk should be moved (e.g.: Townsville and Innisfail in North Queensland during Cyclone Yasi 2010). peopleAtRisk: People who live in hazard zone areas who must be evacuated. evacuationPlan: The plan of evacuation that needs to be followed by all stakeholders involved (e.g. “Emergency Management Australia (EMA) Flood Evacuation Plan”). O p e ra ti o n s performPublicEvacuationProcedure(): A process to implements the evacuation procedure by all victims and emergency teams. alertWithDisasterWarning(): A situation which requires people to listen to a nominated radio station or watch a nominated TV channel for further advice regarding the evacuation warnings. makeEvacuationDecisionWarning(): A process of the authority making a decision as to whether to evacuate or not, which will be assisted by the availability of timely and relevant information. broadcastPublicDisasterWarning(): A process of disseminating the evacuation information and warning through a variety of media (print, electronic, community announcement, word-of-mouth, etc). evacuatePeopleAtRisk(): A process of evacuating the victims by the response emergency teams with a special consideration of special needs victims. setupAndOrganizeEvacuationCentre(): An establishment and management of the evacuation centres which provides basic human needs including accommodation, food, water, first aid, hygiene facilities, clothing, blankets, information and referral services, among others. returnEvacuee(): A final stage of the evacuation process. It will be necessary to assess the disaster area to determine if return is possible and identify any special conditions which may need to be imposed. 3.3 DMKR Detailed Design We use a database management system to implement the components of DMKR. It has these four components to support modelling, storage and retrieval : a) Consistency Checker Module, b) Metamodel Formulation Module, c) Modelling Constructor Module, d) DMM Concepts Database. Each of these components is detailed in this section. 3.3.1 Consistency Checker Module Model transformations, at M2, M1 and M0 levels, are specified via a set of rules defining the modelling constructs and model composition mechanisms for its DMKR modelling design activities. The Consistency Checker Module is a library of these rules which act as policy guidelines for the correct utilisation of the DMM modelling components. The module ensures compliance of model transformations to these rules. The rules define semantic properties of metamodel transformations as prescribed in Wachsmuth (2007) and Lammel (2001). Thus a consistent transformation from a source model (DMM) to a corresponding target model (either an M1-Model or an M0-User Model) is guaranteed. Figure 8 shows a sample of six rules (for the Rule_ID of R04c, RR04a, R04, RR03a, and RR06). For example Rule RR04a formalises the creation of an “Instance model of DMM”: DMM Rule RR04a Rule Syntax : Ґ(µDMM) := [ ι (µDMM) |= µDMM ] Rule Meaning : The set of all DM model (metamodel instances) conforming to a Disaster Management metamodel, µDMM RR04a rule ensures each newly created DM model (metamodel instances) is compliant to the DMM, (µDMM). This rule will mostly be used in association with other rules according to the type of model being developed. For example, if User A wants to develop a new Preparedness model from the DMM, a rule specific to initialise the element is used: DMM Rule RC01b Rule Meaning : The set of concepts for a Preparedness model Rule Syntax : CM (µDMMp) ::=[PreparednessPlan, PreparednessOrganization, PreparednessTask, SuppliesRegistry, Warning, PreparednessGoal, Evacuation, BeforeDisaster, Event, DecisionMaking, Administration, EmergencyPublicInformation, Pre-Position, DisasterFactor, Exposure, DisasterRisk, Training, PreparednessTeam, Media, MutualAidAgreement, PublicEducation, PublicAwareness, Resource, Monitoring, AidAgency] Figure 8 An extract form the rules repository 3.3.2 Metamodel Formulation Module DMM classes are stored as a Concept_table and DMM corresponding phase classes are stored in Phase_table. Figure 9 shows the relationship between both tables in which: a) shows a table’s relationship, and b) shows data values of each tables. In this figure, the MitigationPlan is a concept in the Mitigation-phase class (Phase ID =1). In Concept_table, the Concept_ID of the concept has the same ID with the M2Fragment_ID, AM01. This shows how one M2-Fragment exists for every single concept in DMM. To formalise the usage of concepts in each M2- Fragment (a DMM class), specific rules in the Consistency Checker Module are used. The following four rules formalise the Instantiation of a concept (Rule R04a and R04b) and a Conformance of model (Rule RR07a and RR07b) for two M2-Fragments (the Mitigation and Preparedness class): DMM Rule R04a Rule Syntax : CM (µDMMm) Rule Meaning : Mitigation Concepts of the Disaster Management Metamodel Rule Construct : MitigationConcept::= () DMM Rule R04b Rule Syntax : CM (µDMMp) Rule Meaning : Preparedness Concepts of the Disaster Management Metamodel Rule Construct : PreparednessConcept::= () DMM Rule R07a Rule Syntax : ι(µDMMm) Rule Meaning : Mitigation Model of Disaster Management Rule Construct : MitigationModel::= ( AND ) AND ( AND ) DMM Rule R07b Rule Syntax : ι(µDMMp) Rule Meaning : Preparedness Model of Disaster Management Rule Construct : MitigationModel::= ( AND < PreparednessM1Fragment>) AND ( AND < PreparednessM0Fragment>) Figure 9 Relationship between Concept and Phases; (a) Concept_table and Phase_table, (b) Data values of the Concept_table and Phase_table Rule R04a ensures that every single mitigation-phase concept consists of a DMMClass and a model fragment. Rule R05a ensures that the Mitigation-phase model (DM solution model of DMKR) consists of an M1-Model and an M0-DM User Model derived from the Mitigation-phase class. The different fragments and their associated models are managed through the storing of data for Fragment (M2Fragment_table, M1Fragment_table and M0Fragment_table) and Model (M2Model_table, M1Model_table and M0Model_table). A single DMMClass has only one M2-Fragment and the combination of all M2-Fragments form the M2-Model (Metamodel). As shown in Figure 9 (a), the DMM has many M2-Fragments in the model. As shown in Figure 9 (b), at any one time many M1- models may consist of many M1-Fragments and many M0-User Models may consist of many M0-Fragments. Table 3 shows an example of M2-Fragments with its respective unit fragments that belongs to the MassCasualtyManagement class. These fragments underpin the formulation of M1 and M0-Fragments and models. Table 3 Part of Unit Fragments of the MassCasualtyManagement class Unit ID Unit Name Unit Description CR24a Tactical Procedure The procedure which provides standard guidelines for mass casualty operation in a multi-casualty emergency medical situation. CR24b Organization Structure The organisational structure of multi-responsible teams who are responsible for the overall management of multi-casualty incidents (e.g.: Patient Transportation Group, Medical Supply Group, Medical Communication Group, Victims Treatment Group). CR24c Equipment The equipment needed to perform a mass casualty operation (e.g.: disaster kits containing bar coded wrist bands, envelopes for storing victim's items, sealed bags for storing dead bodies for medical treatment or mortuary). oCR24a Mass Casualty Setup The implementation of mass casualty procedure (e.g.: prepare disaster kits containing: bar coded wrist bands, different sized envelopes for personal effects, a collection of all items taken from the victims, dead or alive, and place them in the bags. Sealed bags are transported with the victims for medical treatment or the mortuary). oCR24b Classify Casualty Classifying the victims of a disaster (e.g.: victims who died in the Medical Post (MP) certified by the MP Doctor. Victims who died in the field need to be taken to the hospital and certified by a qualified doctor). oCR24c Move Patient The movement of patients from the scene of the incident to medical facilities in close coordination within the Treatment Dispatch Manager(s) in the Medical Group and the medical facilities. Figure 10 shows the M2-Fragment of an Evacuation Class with its corresponding Unit Fragment. M1-Models describe a specific DM problem. An M1-Model is formed by many M1-Fragments. M1-Fragments can be instantiated to represent many M0-Fragments (real world data). Examples of suitable candidates to be represented as Figure 10 The M2-Fragment of an Evacuation Class with its respective Unit Fragment Figure 11 The M1-Model of a Disaster Mitigation Model M1-Models are: preparedness operations before floods, the coordination of resources during a flood response, and the reconstruction and rehabilitation following a bushfire. In Section 4.0, real-world DM problems for various bushfire problems are used to implement M1-Models. For example, a Disaster Mitigation Model is the M1-Model conformance from the Mitigation-phase class. This model is created from a combination of a few DMMClass: the StructuralMitigation, the Insurance, the Non-StructuralMitigation, the NeedsPlanning, the RiskAnalysis etc. By using a few unit fragments taken from each class, this model can later be formed. The relationship between the M1- Figure 12 An M0-Fragment of the HomeRadiationMonitoringDetection, is instantiated from an M1-Fragment of the PerformPublicEmergencyPlanModelling Decision associated with Activity Tasks Activity Tasks SetupStructuralMitigationPlan(), a unit fragment of the StructuralMitigation concept Model and M1-Fragment can be described as for each M1-Model; the model has many M1-Fragments. In Figure 11, one unit fragment of a ‘setup structural mitigation plan’ is instantiated from the StructuralMitigation class. For this Instantiation process, a special notation is used to link a relationship between model-metamodel. The stereotype notation of (<>) is used to signify that the SetupStructuralMitigationPlan() is a class operation that comes from the StructuralMitigation class (shown by an arrow). Other instances of unit fragment taken from the DMMClass are: a ‘perform risk analyses’ from the RiskAnalysis, and a ‘perform hazard assessment’ from the HazardAssessment class. Figure 12 shows a sample of one M0-Fragment, Home Radiation Monitoring Detection, in DMKR that represent DM knowledge of a Nuclear Radiation problem. This is instantiated from the M1-Fragment, PerformPublicEmergencyPlan(), which in turn is derived from the M2-Fragment, PreparednessTask. In this M0-Fragment, the real activity of how a home radiation monitoring detection process should be conducted during a nuclear disaster situation is demonstrated. 3.2.3 Modelling Constructor Module The Modelling Constructor Module contains the library of notations/symbols that can be used by system users to develop their semantic DM model in DMKR. In this paper, modelling notations offered by the Unified Modelling Language (UML) are used. A model derived from DMM can be modelled according to UML-based representations: a) ‘Class Diagram-view’ (instantiation of concepts is in form of Class), b) ‘State Transition Diagram-view’ (mapping events – start, stop, condition etc.), c) ‘Use Case Diagram-view’ (model actors and their respective functions), or d) ‘Sequence Diagram-view’ (model activity sequence order). Modelling Constructor Module is the library that provides notations for customisation in DMKR. The representation of a derived M1-Model during a conformance of the model from the DMM is another issue in DMKR. As described by Brottier et al. (2006), a transformation offers an opportunity to improve the readability of the M1-Model rather than use the same notation. Sometimes, improving the readability of the model may involve hiding some relationships in the M1-Model. Therefore, when users create the M1-Model in a class diagram-view, the representation of the model can be seen exactly as its conformant metamodel (because the DMM is developed in this view). However, in other certain cases, users can also present their new M1-Model in a human-friendly representation such as the State Transition Diagram or in Use Case Diagram (UML models). DMKR gives flexibility for a system user to create their model in the modelling environment provided in the system. 3.2.4 DMM Concepts database This database is implemented as the following three smaller databases: 1. The DMMClassTerminology database: This contains DMM concept definitions. 2. The DMMClassRelationship database is the collection of relationships between concepts within and across Mitigation, Preparedness, Response and Recovery-phase class of concepts (M2-Level). These relationships guide users on integration of model components (concepts) as they create a new model for their DM context. For instance, when a user creates a new M1-Model model of the “Earthquake Rescue Model”, one of the important elements that will be derived from the Response-phase class is the Rescue concept. In the M2-Fragment corresponding to this concept, there are seven relationships to other concepts that users need to consider in formulating their M1-Model e.g. “IsPerformedBy” linked to the EmergencyManagementTeam concept or “Follows” linked to the “EmergencyPlan” concept. 3. The third database specifies the attributes and the operations of each class. To illustrate this, Figure 13 shows three attributes for the Evacuation concept: evacuationRoad, evacuationCentres and evacuationAlertProcedure. It also shows three operations: performPublicEvacuationProcedure(), evacuatePeopleAtRisk() and setupAndOrganizeEvacuationCentre(). 4. Demonstrating DMKR in Real-world Disaster Problems: Bushfire Case Study In DMKR, system users are given flexibility to prepare their model. How a model can be formed is varied according to the intention of the user for their new model. This section illustrates how knowledge can be stored and later retrieved and reused using DMKR. An focusing on Bushfire knowledge is shown. In Section 4.1, the storage of Bushfire knowledge is shown. In Section 4.2, retrieving this knowledge according to varying bushfire scenarios is illustrated. 4.1 Storing Bushfire Knowledge in DMKR Bushfire management knowledge is typically available in sources in text form available in reports, books and disaster-related websites. Storing this knowledge begins following the structure of the M2-Fragment, DMMClass). For starters, knowledge for the ResponseTask for a bushfire is stored, based on previous bushfire experiences describing how various DM users operate during the response phase. Their specific actions and roles are stored. Knowledge is collected from the following sources: a website (Johnston 2009); a report (Emergency Management Australia (EMA) 2000); and four books (Paterson 2007), (Troy and Kennedy 2007) (Machin and Hentze 2007), (Stephens and Collins 2007). The stored knowledge combines knowledge of different groups of stakeholders. For example, solution taken from Stephen and Collins (2007) provides knowledge of three different groups: i) media, ii) emergency team, and iii) affected people and community, whereas, a solution from Machin and Hentze (2007) provides knowledge for the emergency team and monitoring user. The knowledge stored in the M0-Fragment of the ResponseTask concept represents tasks of different users. Later other groups of users (e.g.: task of government, task of people at risk or task by media and etc.) will be able to reuse this knowledge. Figure 13 Samples of data values for the Attribute_table and the Operation_table Further bushfire knowledge is sourced from the report of the ‘2009 Bushfire Royal Commission Final Report’ (Parliament of Victoria 2010). This knowledge is presented through Figures 8.1 (a) to (c). The report describes the real experiences of the bushfire tragedy of February 2009 in Victoria, Australia. This was a huge tragedy, claiming 173 lives, destroying at least 1834 homes, rendering 7500 people homeless and releasing millions of tonnes of carbon into the atmosphere. Figure 14 (a) describes knowledge of bushfire factors related to this tragedy. The knowledge is stored as an M0-Fragment of the DisasterFactor concept. In Figure 14(b), the Recommendation 48 from the report describes knowledge for StructuralMitigation. Figure 14(c) contains knowledge for the Legislation concept captured from Recommendation 27. Unlike knowledge stored in the ResponseTask concept which categorises bushfire knowledge according to users: government, people at risk, media. Figure 14 categorises the knowledge according to DMM concepts: DisasterFactor, StructuralMitigation and Legislation. Data presented in Figure 14(a) is a collection of knowledge representing identified factors in the 2009 Victoria Bushfire. This is stored in DMKR as illustrated in Table 4, as DMMClassAttribute of the DisasterFactor concept: the GravityFactor, the TriggeringFactor and the ComplexityFactor. (a) 2009 Victorian Bushfire factors knowledge data, the new case entry for the DisasterFactor concept in Preparedness-phase class (b) Recommendation 48 of ‘2009 Bushfire Royal Commission Final Report’ (Parliament of Victoria 2010), the new case solution for the StructuralMitigation concept (c) Recommendation 27 of ‘2009 Bushfire Royal Commission Final Report’ (Parliament of Victoria 2010), the new case solution for the Legislation concept Figure 14 Bushfire experiences knowledge derived from one knowledge source: 2009 Bushfire Royal Commission Final Report. The experiences knowledge are fragmented into three different DMM concepts: (a) DisasterFactor (b) StructuralMitigation (c) Legislation concept Is stored as an M0-Fragment of the StructuralMitigation  Rapid fire spread followed ignition, which responding crews could not contain.  Fires crowned in forested areas, which made them impossible for ground crews to control.  Powerful convection columns were generated above the fires.  Extensive forward spotting occurred as a result of the fuel type, the weather conditions and the topography.  Late in the day a wind change altered the direction of fire spread and extended the fire front. Is stored as an M0-Fragment DisasterFactor of Preparedness phase Is stored as an M0-Fragment of the Legislation Detailed DisasterFactor knowledge is structured into small unit fragments of M0-Fragments (in the DisasterFactor concept), as follows: The DMMClassAttribute of the GravityFactor: 1) Temperature: 28-30 Jan 2009 - consecutive hot days above 43 C (109 F), with peaking at 45C (113 F) on 30 Jan – 3rd hottest day in the city’s history. Hottest: 46.4 (115F). 2) Hot tropical air to South Eastern Australia is caused by a) Heatwave cause by a slow moving high-pressure system over the Tasman Sea; b) Intense tropical low located off the North West Australian coast; c) Monsoon trough over Northern Australia; and d) the weather conditions and the topography. Late in the day a wind change altered the direction of the fire spread and extended the fire-front. 3) Low humidity. The DMMClassAttribute of the TriggerFactor: 1) Power lines ignition - Rapid fire spread followed ignition, which responding crews could not contain, 2) Lightning, Cigarette butts, 3) Sparks from a power tool - Powerful convection columns were generated above the fires. The DMMClassAttribute of the ComplexityFactor: 1) Major drought more than a decade, 2) 50-year warming trend link to human induced climate change, 3) Extensive pyrocumulus clouds (most intense firestorm ever experienced in Australia history). Table 4 Storing knowledge of DisasterFactor of the 2009 Victorian Bushfire 4.2 Deriving new bushfire solution models from DMKR In this section, the functionality of DMKR as a DM modelling tool is presented. In DMKR based modelling, users are given flexibility to utilise the functionalities facilitated by DMM. In the rest of this section, the modelling capabilities of DMKR are illustrated in two illustrative bushfire scenarios. Scenario 1 presents how knowledge retrieved directly from the specific M0-Fragments can be used as the inputs to create an M1-Model of the Aerial Fire Fighting Strategy model. The models required in this scenario are developed bottom up. In Scenario 2, knowledge of an M1-Model initially created in M1-level is refined into M0-Fragments of two M0-User Models. The models required in this scenario are developed top-down. The 2009 Victorian bushfire factor knowledge is stored to the DisasterFactor concept through its M0-Fragment of the ‘GravityFactor’ Scenario 1: Supporting Aerial Fire Fighting Model process using DMKR (M0) knowledge In this scenario, the reuse of knowledge retrieved from various M0-Fragments to support the user to generate an M1- Model is shown. The user here aims to develop the Aerial Fire Fighting model. The development of this model requires other knowledge that needs to be studied before it can be constructed. For instance, knowledge of many aerial fire suppression factors is crucial for planning an efficient aerial bushfire fire fighting operation as described next. Scenario 1: “The use of aerial fire fighting resources has grown steadily over the past few decades and aircrafts now play an integral role in fire management and suppression in Victoria. In 1997-98 the then Department of Natural Resources and Environment operated the largest fleet of firebombing aircraft ever used in Australia including, for the first time, an Erickson Air crane, a large helicopter that is used for firebombing. An evaluation of the effectiveness of this fleet of aircraft was commissioned by Department of Sustainability and Environment (DSE) and published in 2003. A Bushfire Cooperative Research Centre (CRC) team tries to create a framework model of the effectiveness and efficiency of aerial fire-fighting in Australia. Key findings from this study should include: The effectiveness of aerial fire suppression depends on many factors, including suppressant agent used (retardant, foam or water), aircraft characteristics, drop characteristics, fire intensity, fire size, fuel type, pilot skill, aircraft travel time, distance from fire, ambient conditions, availability of support ground resources, and organisational and infrastructure arrangements.” (2009 Victorian Bushfires Royal Commission 2010) For this kind of problem, a study of different aerial fire suppression factors such as “suppressant agent used, aircraft characteristics, drop characteristics, fire intensity, fire size, fuel type, pilot skill, etc” are required. DMKR can support this by providing DM knowledge of the aerial fire suppression factors from its repository. These factors can be derived through the M0-Fragments of related DMM concepts. For example, through an M2-Fragment of the ResponseTask concept, the DMMClassAttribute of the concept, the ‘ResponseTaskFactor’ stores knowledge of various real-world responses task operation’s factors in the M0-Fragments of the concept. Particularly for the ‘suppressant agent used’ factor, knowledge earlier sourced from Emergency Management Australia (EMA) of can be reused. A sample of the relevant M0-Fragment in DMKR is as follows: ... If Fire-fighting OBJECTIVE = ("For common solid and combustible materials") Then USE = ("WATER") If Fire-fighting OBJECTIVE = ("For extinguishing fires that is flammable and combustible liquids") Then USE = ("FOAM") If Fire-fighting OBJECTIVE = ("Effective as a smothering and chemical chain reaction") Then USE = ("EXTINGUISHING POWDER") If Fire-fighting OBJECTIVE = ("For extinguishing small fires and fires involving electrical equipment") Then USE = ("CARBON DIOXIDE") If Fire-fighting OBJECTIVE = ("For extinguishing chemical chain reaction-inhibiting") Then USE = ("VAPORIZING LIQUID") If Fire-fighting OBJECTIVE = ("To react to form a smothering soap layer on the surface of burning fats") Then USE = ("WET CHEMICAL") If Fire-fighting OBJECTIVE = ("For extinguishing combustible chemical") Then USE = ("SPECIAL AGENTS") … In addition to the above, DMKR contains knowledge of similar processes (choosing a right fire fighting agent) implemented by other countries. This knowledge can support the CRC’s team in their study. In addition, knowledge other factors, for example, the ‘aircraft characteristics’ can also be retrieved for reuse. ‘ResponseTaskEquipment’ is another DMMClassAttribute of the ResponseTask concept. This knowledge is also sourced from practices of other countries and is retrieved straightforwardly as M0-Fragments. These include how: a) China uses “Metropolitan Aerial Fire Fighting System for the EC 225 Helicopter Simplex Model 516”; b) USA through its Los Angeles County Fire Department uses “Sikorsky S-70C Fire Hawk”; c) Italy through Italian Civil Protection Department uses “Bombardier Canadair CL 415 Aircrafts”; d) Ukraine uses the “Antonov 32 Aircraft”; and e) Germany uses the “KFOR helicopters etc (sources from Euro-Atlantic Disaster Response Coordination Centre (EADRCC) 2007)” in their aerial fire fighting operations. Efficiency of an aerial fire-fighting strategy also depends on fire behaviour analysis. Through an M2-Fragment of the Monitoring concept, the DMMClassOperation of the ‘EventAnalysis’ represents knowledge of how to monitor analyses disaster data. Specific for the purpose of the CRC team, the following M0-Fragment for the bushfire fire behaviour analysis is also reusable: --------------------------------------------------------------------------------------------------- ACTIVITY TASKs: EventAnalysis (M0-Fragment of the Monitoring concept: 1) Use current bushfire events data (Humidity Percentage, Air Temperature degree Celsius, Average Wind Speed, Slope Position, Fuels Loads, Fuel Type, Fuel Mixture, Steepness, Vegetation Communities) 2) Based on current events data, perform fire prediction analysis (Fire Prediction, Fire Forecasting, Fire Environmental Model, calculating Fire Spread Speed, estimating probability of Fire Ignition, Fire Evaluation based on weather, calculating Fire Danger Index) and perform Fire Behaviour Prediction Analysis. 3) Send event analysis results to Emergency Operation Centre. FIRE BEHAVIOR PREDICTION ANALYSIS: i) FIRE SPREAD SPEED: [ D = 1.15(5 + 0.5v) ] Description: This subroutine representing fire spread speed to leeward. Where v is a wind velocity meter per second (m/sec) and D is the limit of distance which fire can spread (m). ii) FIRE SPREADING PROBABILITY: [ Fij = a. (Sij . Pij). W Bij. P (tckl)] Description: The fire spreading judgement, that is whether or not cell ij changes from one state to another, is done by using the fire spreading probability of cell ij. The probability is given by the fire spreading judgement index Fij. This is calculated for all cells ij within the neighbourhood of cell kl and defined by this equation. iii) POINT OF FIRE ORIGIN: [ tx = (3 + 3a/8 + 8d/D) / (1+0.1v)] Description: This equation shows the time until an adjacent house to the point of fire origin ignites after catching fire in the origin. Where, a is a length of average of a side in building (m), d is a pitch of building (m) and D is the limit of distance which fire can spread (m). iv) CONTINUATION TIME OF FIRE: [ty = (w/5.5)/(Aw /'H / Af) Description: The time t2 until cell kl burns out after catching fire is defined in this subroutine. Where, w is a fire load (kg/m2), Aw is a opening area (m2), Af is a floor area (m2) and H is a height (m). This equation approximately represents the continuation time of fire as assuming wooden building and constant combustion speed v) PROCESS OF FIRE SPREADING: [ IF Nij(t) = 1 and Fij > ran then nij(t+1) = 2] Description: Fire spreading judgement index Fij of a selected cell ij is calculated in fire spread model. If Fij is satisfied with the following requirements, the set of cell ij becomes nij = 2 (Catching fire). This subroutine calculates nij. Where nij (t) is the state of cell ij at simulation time t and ran is the random number which takes from 0 to 1 vi) FIRE EXTINGUISHED UTILISATION: [ Ce = (Vw/(Cw.tf)). Rw] Description: The number of cells of which the fire can be extinguished with water utilisation, Ce, is given in this equation. This is based on the assumption that one nozzle continues spraying water to a cell of state until extinction of the cell …. Scenario 2: Creating Process Models (M1) and User Models (M0) for a new Bushfire Mitigation Plan process The derivation of an M1-Model using DMKR to setup a bushfire mitigation plan is presented in the following scenario: “The Head of Operation Engineer at a government-owned electric power company (SWEPCO) in Australia has been requested to prepare a bushfire mitigation plan for his company. SWEPCO is a company which has the responsibility for power sector operations such as dispatching electricity to different public local areas, generate electricity, operates power hydro stations and many more electrical operational works. The requirement is to develop a specific bushfire mitigation plan for this company as a result of many recent reported bushfire events in several of the company’s client’s locations. Therefore, a company preparedness strategy is required to overcome any unforeseen bushfire events in the future. As this will be the first time for this SWEPCO head engineer to prepare a plan that he has no prior experience of, this user definitely requires some support for preparing this task. The information of how to start the mitigation plan process, how to set up a strategic planning committee, which rules and legislations are relevant to bushfire problems, or what are the structural or non-mitigation appropriate for the plan are important for this user.” In this scenario, the SWEPCO’s engineer will be directed to the Mitigation-phase class represented in the Metamodel Formulation module. This is because the ‘Setup Mitigation Plan’ is recognised as a part of mitigation activities by the Consistency Checker Module. The engineer is then offered information on all the concepts (DMMClass in Mitigation-phase) from which he is able to derive his own DM model (M1-Model of Setup Mitigation Plan for SWEPCO Company). 21 such concepts exist. Class Diagram-view (Figure 15) is one M1-Model possibility which contains 11 concepts in the Mitigation-phase class selected for his model. This now becomes the M1-Fragments of the SWEPCO Setup Bushfire Mitigation Plan Model. Based on the M1-Model created by this user, the next step is to use DMKR to generate data for his M1-Model’s M1-Fragments. The collection of existing DM knowledge case solutions is stored in a repository that matches the inputs (bushfire knowledge) for the M1-Model entered by this user that will be retrieved. For this example, two such models are available in DMKR based on sources earlier collected from Powercor Australia Ltd (Powercor Australia Ltd 2011) and the United Energy Company (United Energy 2011). These provide bushfire mitigation knowledge specific for an electricity company which match the intention of the M1-Model (Mitigation plan model - Figure 15) as specified by the user. Generally for such users, electricity networks are a serious fire ignition hazard. Prevention is very important due to enormous cost associated with such disasters. For Powercor Company, the bushfire mitigation model includes processes for asset inspection, maintenance, construction, upgrading, replacement, vegetation management, performance monitoring and auditing processes. This strategy plan applies to assets that could cause fire ignition in areas designated as hazardous bushfire risk areas. For the United Energy Company, its bushfire mitigation plan model concentrates more on the policies and procedures used to demonstrate the commitment from all levels of management within the company to the minimisation of bushfire risk due to electricity assets. Figure 15 The Setup Mitigation Plan Model (M1) derived from the Mitigation-phase class The weather conditions for the two M0-User Models retrieved match SWEPCO’s operating conditions. The bushfire conditions in Australia faced by the two companies are equivalent to SWEPCO’s problem situation. Information derived from Powercor and United Energy provide relevant and significant bushfire knowledge for SWEPCO’s plans formulation. For instance, specific to the StructuralMitigation, based on the derived knowledge retrieved from the two sources, different kinds of structural mitigation processes are found to be conducted in their mitigation plans. The structural mitigation plans of Powercor include : a) The management of vegetation around power lines, b) Inspect private overhead electric lines, and c) The implemented new technologies to minimise risk of electricity assets causing fire ignition, whereas, for the United Energy the plan stresses: a) Electric lines clearance, b) Asset management system, and c) Procurement of equipment and services. From the retrieval of this knowledge, it is identified that the procedure used (data in the M0-Fragment) to check the technology and equipments standard in each plan is different. Powercor uses the ‘Technical Standard EA121 - Overhead - Bushfire Mitigation’ and United Energy uses the ‘Equipment Materials Approval Document No.JEN PR 0070 WI 04’. This information gives richness to the bushfire mitigation plans for the SWEPCO M1-Model. Hence, by using the M1-Model created in Figure 15, the real-world bushfire knowledge source of the two companies will be presented as the retrieval result for the SWEPCO’s new M1-Model. The two new M0-User Models are shown in Figures 16 and 17. Figure 16 The retrieval of model solution (M0) for the Powercor Mitigation Plan (M1). Figure 17 The retrieval of model solution (M0) for the United Energy Mitigation Plan (M1). The M0-User Model 1 source from Powercor Australia The M0-User Model 2 source from United Energy Even though sources from Powercor and United Energy are chosen as a solution for the SWEPCO case, the repository of DMKR also has a population of others similar model samples: the Berlin Wildfire Hazard Mitigation Plan from New Hampshire, USA (North Country Council 2007), the Fire Hazards Mitigation Plan from the Navi Mumbai Municipal, India (Navi Mumbai Municipal Corporation 2010) and many other fire mitigation solutions. In this section, the functionalities of the Metamodel-based DMKR system were demonstrated in real world DM scenarios. Specifically, real-world DM bushfire scenarios were visualised. Collecting and storing of bushfire knowledge experience from different bushfire knowledge sources showed the capability of DMKR for DM knowledge storage. The collected knowledge was later reused to solve other incoming bushfire problem scenarios faced by other users. This process demonstrated the potential of this system as a DM modelling tool. Moreover, derived solutions were also reusable and this was also demonstrated. Utilising DMKR, DM users in different bushfire scenarios were presented with new derived DM solutions suitable for their real world problems. 4. Conclusion and Future Works This paper illustrates a new a metamodelling based approach to guide DM practitioners to store and reuse DM based on a Disaster Management Metamodel (DMM). It presents a knowledge sharing system, DMKR 1.0, to uniformally store and structure DM knowledge. This is facilitated by a specific a DM language. DMKR facilitates the derivation of new DM solution models using the DM language, underpinned by the metamodel DMM. DMKR successfully combines the use of DMM for storage, retrieval and modelling to describe modelling capability for any specific disaster. To DM practitioners therefore, the paper offers a coordinated approach and activities to achieve DM goals where DMKR can act as a central tool for creating, organizing and managing DM modelling knowledge. Through fragmenting DM knowledge experience for reuse, DMKR guides DM users to achieve specific DM goal. Many stakeholders are either directly involved (e.g.: disaster manager, emergency coordinator, fire fighters..) or indirectly involved in DM operations (e.g.: local businesses, insurance companies etc..) but they do not have a complete view of how different DM activities can be conducted. DMM through its four sets of classes (response, recovery, mitigation and preparation classes) give an overall picture of how all DM actions are executed. With better awareness and understanding of the whole DM processes, many benefits can be derived because ensuring success in initial DM phase will lead to success in the subsequent phases. The paper also contributes to semi-formal knowledge management practices by developing a rigorous modelling hierarchy managed and enforced by DMKR and underpinned by DMM. As the ability to offer modelling guideline to many domain users, DMM helps various users to make quicker decisions using earlier created semantic models. It facilitates three levels of modeling as in the MOF framework: the M2-level for a Metamodel, the M1-level for a Model, and the M0-level for a User Model. Instance models are derived from DMM based on conformance relationships and DM knowledge is structured in the DMKR system using Model Fragment units. Since there are three MOF modelling levels are used in this research to describe the DM knowledge, three corresponding types of Model Fragment (M2-Fragment, M1-Fragmnet and M0-Fragment) are also used. Further future research will support knowledge evolution in DMKR and add further reasoning capacities to support DM first responders: The paper presents the construction of formal semantics of relating DM models at different metamodelling levels. This can form in the future a fundamental part of an automated decision support in many disaster scenarios. By populating knowledge of multiple disaster cases for the same unit fragment, a reasoning process can be easily applied. This would be of significance to DMM, as the use of the reasoning technique through metamodel for is not intensively being yet investigated. Furthermore, such automated reasoning capabilities can also pave the way for the construction of a real-time DM system using models created from the metamodel for a quick response. Since the DMM describes data that should exist in the Response-phase models, real-time calculation can be made when fresh disaster data that is being “pushed” from the field by first responders. This can for example include locations of responders, information on the status of response activities, data mapping damage, and sensor data. Results from the calculation of the data can be pushed back into the field immediately e.g. responder’s team send field reports, imagery and map updates and requests the current status information on resource deployments. References 2009 Victorian Bushfires Royal Commission (2010). Systemic Issues – Aerial Firefighting Submissions of Counsel Assisting Aßmann, U., S. Zschaler and G. Wagner (2006). Ontologies, Meta-models, and the Model-Driven Paradigm. Ontologies for Software Engineering and Software Technology, Springer Berlin Heidelberg: 249-273. Beydoun, G. and A. Hoffmann (1998). Simultaneous Modelling and Knowledge Acquisition using NRDR. 5th Pacific Rim Conference on Artificial Intelligence (PRICAI98), Singapore, Springer-Verlag. Brottier, E., F. Fleurey, J. Steel, B. Baudry and Y. L. Traon (2006). Metamodel-based Test Generation for Model Transformations: an Algorithm and a Tool. 17th International Symposium on Software Reliability Engineering (ISSRE 2006), Raleigh, North California, USA. Colin, A., K. Thomas and hne (2003). "Model-Driven Development: A Metamodeling Foundation." IEEE Softw. 20(5): 36-41. Cook, S. (2004) "Domain-Specific Modeling and Model Driven Architecture." MDA Journal: A BPT Column. Cordner, S. M., N. Woodford and R. Bassed (2011). "Forensic aspects of the 2009 Victorian Bushfires Disaster." Forensic Science International 205(1-3): 2-7. e-objects Open Source MetaModel. (2012). "MetaModel database compliancy in Open Source MetaModel." Retrieved 20 March 2012. Emergency Management Australia (EMA) (2000). Disaster Preparedness Manual for Commonwealth Agencies. Australian Emergency Manual Series, National Archives of Australia. Euro-Atlantic Disaster Response Coordination Centre (EADRCC) (2007). Forest Fires In Albania, Bulgaria And The Former Yugoslav Republic Of Macedonia. EADRCC Executive Summary. Firesmith, D. (2006). Method Engineering Using OPFRO. 11th Annual European Software Engineering Process Group Conference (EuroSEPG). Johnston, S. (2009). "Independent Community Representatives Advocate." The Australian Retrieved 1-3-2009, from http://www.johnston-independent.com/. Kleijnen, J. P. C. and R. G. Sargent (2000). "A Methodology for Fitting and Validating Metamodels in Simulation." European Journal of Operational Research 120: 14-29. Lammel, R. (2001). Grammar Adaptation. Proceedings of the International Symposium of Formal Methods Europe on Formal Methods for Increasing Software Productivity (FME'01), Springer-Verlag: 550-570. Larcombe, P. J., S. E. Moloney and P. A. Schmidt (2009). Pandemic (H1N1) 2009: a clinical spectrum in the general paediatric population. Archieves of Disease in Childhood. Queensland, Gold Coast Hospital. 96: 96-98. Lauras, M., Truptil S., and Bénaben, F. (2015) Towards a better management of complex emergencies through crisis management meta-modelling, Disasters 29 (4), 687–714 Levendovszky, T., B. Rumpe, B. Schatz and J. Sprinkle (2010). Model Evolution and Management. MBEERTS. Berlin Heidelberg, Springer-Verlag. 6100: 241-270. M. Picka (2004). "Metamodelling and Development of Information System." Agriculture Economics 2(50): 65-70. Machin, B. and M. Hentze (2007). Comments on The Present and Future of Wildland Fire Suppression Decision- Making Processes. Living on the Edge: Economic, Institutional and Management Perspectives on Wildfire Hazard in the Urban Interface, Advances in the Economics of Environmental Resource. Elsevier Ltd. 6: 1-12. Navi Mumbai Municipal Corporation (2010). Fire Hazards Response And Mitigation Plan Mumbai, India. North Country Council (2007). Berlin Wildfire Hazard Mitigation Plan. Bethlehem, New Hampshire, USA. OMG (2002). Meta Object Facility (MOF) Specification, Object Management Group. OMG (2003). MDA Guide Version 1.0.1. http://www.johnston-independent.com/ http://onlinelibrary.wiley.com/doi/10.1111/disa.12122/abstract http://onlinelibrary.wiley.com/doi/10.1111/disa.12122/abstract Othman, S. H., G. Beydoun (2013). Model-driven Disaster Management. Information and Management. 50(5), 218-228. Othman, S. H., G. Beydoun and V. Sugumaran (2014). "Development and validation of a Disaster Management Metamodel (DMM)." Information Processing & Management 50(2): 235-271. Panesar-Walawege, R. K., T. S. Knutsen, M. Sabetzadeh and L. Briand (2011). CRESCO: construction of evidence repositories for managing standards compliance. Proceedings of the 30th international conference on Advances in conceptual modeling: recent developments and new directions. Brussels, Belgium, Springer-Verlag: 338-342. Parliament of Victoria (2010). 2009 Victorian Bushfires Royal Commission. Victoria. I,II,II and IV: 41. Paterson, R. G. (2007). Wildfire Hazard Mitigation As Safe Smart Growth. Living on the Edge: Economic, Institutional and Management Perspectives on Wildfire Hazard in the Urban Interface, Advances in the Economics of Environmental Resource. Elsevier Ltd. 6: 1-12. Powercor Australia Ltd (2011). Bushfire Mitigation Strategy Plan 2011-2012: Electricity Safety (Bushfire Mitigation) Regulations 2003, Document No: 05-M810. F. Audley: 68. Saltor, F., M. García-Solaco and P. Gargallo (1993). Diversity with cooperation in database schemata: Semantic relativism. In Proc. ICIS Conference. Shanzhen, Y. and L. Yuntao (2011). An intelligent information sharing method of heterogeneous geographic data based on unified metamodel and entity matching. Geoinformatics, 2011 19th International Conference on. Shiva, S. G. and L. A. Shala (2007). Software Reuse: Research and Practice. Information Technology, 2007. ITNG '07. Fourth International Conference on. Stahl, T., M. Voelter and K. Czarnecki (2005). Model-Driven Software Engineering, Technology, Engineering, Management, John-Wiley & Sons Ltd. Stephens, S. L. and B. M. Collins (2007). Fire Policy In the Urban Wildland Interface (UWI) In the United States: What Are The Issues and Possible Solutions? Living on the Edge: Economic, Institutional and Management Perspectives on Wildfire Hazard in the Urban Interface, Advances in the Economics of Environmental Resource. Elsevier Ltd. 6: 1-12. Trabelsi, C., R. B. Atitallah, S. Meftali, J.-L. Dekeyser and A. Jemai (2011). "A Model-Driven Approach for Hybrid Power Estimation in Embedded Systems Design." EURASIP Journal on Embedded Systems (Article ID 569031): 15 Tran, N., G. Beydoun and G. Low (2007). Design of a Peer-to-Peer Information Sharing MAS Using MOBMAS (Ontology-Centric Agent Oriented Methodology). In Advances in Information Systems Development, W. Wojtkowski, W.G. Wojtkowski, J. Zupancic, G. Magyar and G. Knapp (eds.). Springer US, 63-76. Troy, A. and R. G. Kennedy (2007). Finding Solutions To The Urban Wildland Fire Problem In a Changing World. Living on the Edge: Economic, Institutional and Management Perspectives on Wildfire Hazard in the Urban Interface, Advances in the Economics of Environmental Resource. Elsevier Ltd. 6: 1-12. United Energy (2011). Bushfire Mitigation Plan 2011-2012, Document No: UE PL 0009. T. Fisher: 130. Vara, J. M., B. Vela, V. A. Bollati and E. Marcos (2009). Supporting Model-Driven Development of Object - Relational Database Schemas: A Case Study. Proceedings of the 2nd International Conference on Theory and Practice of Model Transformations. Zurich, Switzerland, Springer-Verlag: 181-196. Viswanathan, G. and M. Schneider (2010). BigCube: A Metamodel for Managing Multidimensional Data. International Conference on Software Engineering and Data Engineering (SEDE 2010). I. Rahal and R. Zalila- Wenkstern. USA, ISCA: 237-242. Vytautas Stuikys, R. D., Aleksandras Targamadze (2010). "A Model-Driven View To Meta-Program Development Process." Information Technology and Control 39(2). Wachsmuth, G. (2007). Metamodel Adaptation and Model Co-adaptation. Proceedings of 21st European Conference on Object-Oriented Programming (ECOOP), Berlin, Germany, Springer-Verlag. Xu, D., C. Wijesooriya, X.-G. Wang, G. Beydoun (2011), Outbound logistics exception monitoring: A multi- perspective ontologies’ approach with intelligent agents, Expert Systems with Applications, 38 (11), pp. 13604– 13611.