Semantic Integration of Sensor Data and Disaster Management Systems: The Emergency Archetype Approach

The Semantic Sensor Web (SSW) allows emergency response management (ERM) systems to consume sensor data and improve response time and effectiveness. It is also a fact that ERM must be carried out as a multiorganizational task to combine sensor data with human decisions and observations. A frequent problem in such scenarios is that current formats for data exchange do not support sensor data in a way that allows semantic interoperability between heterogeneous ERM systems. Therefore, part of the semantic richness coming from the SSW, such as the Semantic Sensor Network Ontology (SSNO), is lost when sensor data is embedded in current ERM messages. To bridge the gap, an application of the two-level paradigm to the ERM domain is proposed. The advantages of using “emergency archetypes” include semantic data integration and flexibility to represent new types of messages, without losing the support for seamless exchange between heterogeneous ERM systems. Emergency archetypes can reuse the terminologies and ontologies available in the ERM domain so that systems based on previous formats can switch to archetypes in a straightforward process. Finally, a method to attach rules to emergency archetypes is explained, allowing not only the semantic interoperability of ERM data but also of the inference knowledge that trigger alerts and support decision making.


Introduction and Motivation
In 1999, Neil Gross expressed that "In the next century, planet earth will don an electronic skin.It will use the Internet as a scaffold to support and transmit its sensations.This skin is already being stitched together. .." [1].As a result of the recent increase of real-time data provided by sensors, there has also been an increase in sensor-related fields in order to improve the semantics associated to sensor devices, sensing procedures, and sensor data [2].In addition, sensor discovery [3], sensor annotation for disaster management [4], as well as sensor data mashups and interoperability [5] are being addressed.
All these efforts combined are defining what is known as the Semantic Sensor Web (SSW) [6], whose main objective is the seamless integration of the "electronic skin" mentioned by Gross into information systems.To support interoperability, data formats, including the Sensor Web Enablement (SWE) developed by the OGC (http://www .opengeospatial.org/projects/groups/sensorwebdwg) and the EEML (http://www.eeml.org/)currently used by Cosm (https://cosm.com/), have been proposed.However, it is argued that SWE on its own does not provide sufficient semantic description, only guarantying syntactic interoperability between heterogeneous systems [6].
The term "semantic interoperability" has been used for more than a decade in computer science as the ability to exchange services and data between components of largescale, distributed systems in a way that ensures the requesters and providers to have a common understanding of the meanings of the requested services and data [7].Therefore, the definition of ontologies, such as the Semantic Sensor Network Ontology (SSNO) [8], has been carried out as a part of the SSW to support semantic interoperability during sensor data exchange and to open the gates for the publication of sensor streams as Linked Data [9], for example, as explained by [10].
Thus, the SSW is oriented to save the first frontier in the sensor data flow, that is to say, reaching a central information system.In fact, part of the research cited before has already been taken into practice in European projects within the risk management domain, such as OSIRIS (Open architecture for Smart and Interoperable networks in Risk management based on Sensors (ftp://ftp.cordis.europa.eu/pub/ist/docs/environment/osirisen.pdf)) and SANY [11].Their objective was to specify open architectures and develop decision support services to address the monitoring, preparation, and response phases of environmental risk and crisis management.For the specific case of Tsunamis in Indonesia, the development of the Early Warning and Mitigation System (EWMS), as part of the GITEWS project, makes use of OGC standards as described by Raape et al. [12].
However, such all-in-one solutions or ad hoc developed systems that receive input data from sensors and generate end user warnings are not always possible in the ERM domain.Given that interorganizational communications are required, a second frontier (or ERM internal frontier) must be trespassed once the sensor data is gathered by one of the organizations, and it has to be handled by heterogeneous ERM systems in different organizations.
For example, according to the nuclear emergency plan defined for Almaraz NPP (http://en.wikipedia.org/wiki/SantaMar%C3%ADa de Garo%C3%B1a Nuclear Power Plant) [13], the following organizations must be notified in case of nuclear accident: Operations Coordination Center, Government Delegation, Nuclear Safety Council, and Directorate General of Nuclear Energy.Such exchange between the organizations involved in the ERM process is required to combine sensor data with human observations and decisions, as well as other disaster-related information.Due to the lack of consistent ERM data standards to reach this internal frontier, there is a breakdown of the information supply chain that drastically affects semantic interoperability, as explained in Section 2.
In order to bridge the gap, the OSIRIS project full report [14] recommends the combination of Tactical Situation Object (TSO) (https://www.oasis-open.org/committees/download.php/42411/CWA15931-1.pdf)and SWE for better supporting sensor data in ERM communications, but, at the same time, the research by De Maio et al. [15] and the one by Sicilia and Santos [16] argue that TSO and Common Alerting Protocol (CAP) (http://docs.oasisopen.org/emergency/cap/v1.2/CAP-v1.2-os.html)lack some key semantics.From all the requirements that an emergency warning must fulfill, Botterell and Addams-Moring state that being totally understandable is essential for the overall success of the warning [17].
According to above mentioned problems, the ERM domain would get significant benefits from a communication mechanism being (i) more structured than the current ones, in order to formally represent all the required details about sensor readings, and at the same time, (ii) semantically flexible enough to support the definitions of new ERM messages that deal with new types of disasters, without having to go through significant software and systems modifications.
It should be also noticed that (iii) ERM systems development has classically followed similar steps to those of other IT domains.That is, requirements are gathered via ad hoc discussions with users (typically based on the "use case" methodology), designs, and models built from the requirements, implementation proceeds from the design, followed by testing and deployment and ultimately the maintenance part of the lifecycle.This procedure is usually characterized by ongoing high costs of implementation change and a widening gap between system capabilities and the requirements at any moment.
That approach also suffers from the fact that ad hoc conversations with systems users frequently fail to reveal underlying content and workflow.Besides, the collaboration is rarely effective between the main two groups of professionals interacting in this domain, that is, information science professionals and emergency/disaster experts.Without such collaboration, it is not possible to achieve any efforts at developing more effective and faster ERM systems that interoperate seamlessly at different levels of granularity.On the one hand, ERM experts may not be well versed in the field of information technology, thus being unaware of the technical limitations of certain solutions proposed by them.On the other hand, information science professionals do not have the ERM workflow and the know-how to independently develop systems that meet the requirements of the ERM domain.
In order to satisfy such three needs, the present paper studies the application of the so-called two-level paradigm to the ERM domain.It has been already introduced in the healthcare domain to foster semantic interoperability between electronic health record systems, [18].The rest of the paper is structured as follows.Section 2 analyzes the limitations of the current communications formats in the ERM domain according to above mentioned requirements.Then Section 3 gives a general methodology for the two-level modeling of ERM information, including the description of the Emergency Response Reference Model (ERRM), that is, the low semantic level, and the "emergency archetypes, " that is, the high semantic level.Section 4 follows with an application of the two-level paradigm to the concrete information for managing nuclear accidents in Nuclear Power Plant (NPP).Then Section 5 briefly illustrates the integration of emergency archetypes with SWRL rules in order to support interoperability of rule-based systems and aid decision making.Finally, Section 6 describes the conclusions and further work.

Limitations of Current ERM Formats for Representing Sensor Data
This section analyzes the inconveniences presented by formats, templates, and so forth, in the ERM domain for embedding sensor data in messages and guaranteeing semantic interoperability.The emergency archetypes approach will be concretely applied to a nuclear accident, as an example of CBRN hazardous scenario, given that Spanish NPPs follow International Journal of Distributed Sensor Networks 3 a paper-based procedure to alert first response organizations during nuclear emergencies [13].
Regarding semantic interoperability, such forms contain most of the "paper era" problems, including unstructured/free text and handwritten sections, that severely affect automatic generation and processing of the message.The state of the art includes XML-based protocols such as TSO and CAP, that significantly improve interoperability when compared to the static, paper-based, and NPP messages.Still, neither TSO nor CAP is able to fulfill the requirements for full semantic interoperability when embedding sensor data.

Limitations of TSO and CAP.
The following points illustrate the limitations of TSO and CAP for embedding sensor data.It should be noted, though, that evaluating the usability of CAP for the communication between ERM systems is sometimes not appropriated as CAP is a very simple and general format for exchanging public warnings about allhazards, over all kinds of networks.
(i) Standardizing Specific Alerts.Depending on the source of the emergency, environmental monitoring groups, firefighters, evacuation units, and so forth need to make decisions based on the disaster data.As a result, local templates for the required alerting information (including sensor data, human observations, evaluations of severity, and categorizations of the disaster) are frequently agreed between the involved organizations.A precise definition of what information is required is very important for the success of the emergency response.For example, during a nuclear emergency, the required range of distance between the radioactivity sensor and the source of contamination, as well as the different altitudes at which meteorological data must be collected, are defined.
Therefore, interoperability approaches must be flexible enough to cope with these local templates.Otherwise the adoption of new models by the ERM systems will be delayed, and in many occasions disregarded, because not only technical modifications could be required but also the knowhow can be affected.Neither TSO nor CAP provides such flexibility.For example, in the case of TSO, all categorizations, severities, and enumerations are taken from a controlled and static vocabulary TSO codes (https://www.oasis-open.org/committees/download.php/42412/CWA 15931-2.pdf)and all messages must follow the same large and exhaustive schema TSO XML schema-(https://www.oasis-open.org/committees/download.php/42411/CWA 15931-1.pdf).
(ii) Linking Sensor Data and Disasters.Semantic Sensor Web technologies such as SWE, EEML, and SSNO are designed to seamlessly connect all the variety of sensors devices and their outputs to information systems.However, they have not been designed to attach sensed information to a particular context of a disaster or an accident.On the other hand, TSO and CAP were not designed to properly represent observations and sensor data (see the bullet "preserving sensor data semantics").Therefore, the required link between sensor data and disasters only exists inside ERM systems and cannot be exported as a standard format without losing precision in the data description.
(iii) Preserving Sensor Data Semantics.As it can be appreciated in Table 1, there is a loss of semantics and precision when migrating sensor data from SWE to TSO or to CAP messages.For example, using neither Fahrenheit nor decimals positions is supported by temperatures values in TSO.And an even more significant lack of semantics is exposed when there is no code in the TSO dictionary for the measured property.In such cases, it is not possible, as it is in SWE, to dynamically define the meaning of data based on a widely used ontology like SWEET, so free text is used.This latter case is always the case in CAP, where neither fixed dictionaries nor ontology referencing is supported.
(iv) Creating a History of Measurements.The evolution of casualties is essential for the proper assessment of a disaster and the TSO dictionary includes PRELIM STAT and INITIAL STAT to describe different counts of casualties, there are disasters for which sensor measurements must be taken at predefined milestones.For example, according to the Irish plan to cater for nuclear emergencies abroad that result in radioactive contamination reaching Ireland, (http://www.environ.ie/en/Environment/Environmental-Radiation/PublicationsDocuments/FileDownLoad,1323,en.pdf) between 24 and 36 hours after the nuclear disaster, the level of radioactivity is likely to have peaked.The contamination must be mapped and quantified at that particular point in order to properly manage the postaccident situation.The only mechanism provided by the TSO standard to represent such history milestones is the creation of new messages using the same EVENT ID, but they are not previously defined and there is no semantics attached to them.
(v) Adapting to New Kinds of Disasters.The world is constantly undergoing a sequence of technological, political, and biological changes that may result into new types of disasters, or new response procedures to deal with the same disaster.Examples of new disasters may include new pandemics or contamination by a new substance while new procedures may include assessment of the levels of such new substance using new sensor devices.Both the XML schema and the dictionary supported by TSO are static definitions, the modification of which requires the slow agreement of the CEN and all its members.On the other hand, if free text fields are used to represent the new information, then semantic interoperability is completely lost.That is the case of concentration in the TSO fragment of Table 1.
(vi) Multilingualism.Disaster management may involve organizations from different countries as in the case of a nuclear accident in Cataluña affecting the southwest of France.In such scenarios, supporting multilingualism in the ERM messages is essential in order to achieve semantic interoperability.All the data not associated to a given TSO code in a TSO message is lacking multilingualism.

Two-Level Modeling of Emergency Management Information
In order to address the problems listed in Section 2 and support full semantic interoperability between heterogeneous ERM systems, an approach based on the two-level modeling is here described.Such paradigm was introduced in [18] to improve interoperability in the healthcare domain, the workflow of which presents some analogies with the one typically used in emergency management as it is explained in the following.Clinical practice can be represented as an iterative, care delivery process that starts with observations of the status of the patient.Such observations lead to informed opinions on the part of a health care professional, including assessment of the current situation, goals for a future situation, and plans for achieving the goals.Then those plans become into detailed instructions for clinical practice that eventually trigger the appropriate actions.At this stage, whole reiterations may be needed until the problem is solved [19].
In the ERM domain, Fiedrich and Burghardt [20] consider four ERM stages: preparation, mitigation, response, and recovery.Similarly, the OSIRIS project documentation [14] defines the ERM cycle as follows: preparedness, alert, response, recovery, postdisaster, prevention and mitigation.Such cycles require three kinds of information, which are the breakpoints where communication between independent ERM systems is frequently lost because of data ambiguity and incompatibility.The TSO model defines 4 entities (i.e., EVENT, CONTEXT, MISSION and RESOURCE) related to the core TSOs to support communications in such breakpoints.
The present research considers that the semantic differences between the above mentioned stages or TSO entities generate syntactic differences between the exchanged messages in each stage.Therefore, the reference model proposed in the next subsection supports typed messages than can be then specialized with the emergency archetypes described in further sections.The introduced reference model and archetypes are adaptations to ERM of the ones provided by openEHR (http://www.openehr.org)and EN13606 (http://www.en13606.org/)which are widely used in the healthcare domain.The previous research and developments of this paper's authors have been directly related to such standards, in order to translate them to ontology languages and enrich them with SWRL rules [21], as well as to map them [22].Thus, the purpose of the present research is to adapt such proven mechanism to the ERM domain.

The Emergency Response Reference Model (ERRM).
Given that the above mentioned types of ERM messages are common for every kind of disaster, a generic ERRM can include a logical information architecture for the interoperability of ERM systems.Leaving semantics for the upper level, the ERRM can focus on the structure of the messages and the homogeneous representation of enumerations, tables, lists, codes, text, dates, times, magnitudes, and so forth, all adapted to the requirements of the ERM domain.Whereas TSO includes both syntax and semantic constraints at a unique level, the ERRM includes more complex syntax and grammar constraints and practically no semantics.For example, radioactivity and humidity are both considered as ERRM quantities (i.e., they are semantically equivalent at such level), but, syntactically, they must include their magnitude, unit, and precision as separated fields.Therefore, the ERRM constitutes a base framework that represents the general features of the components of ERM messages, how they are organized depending on the type of message (i.e., SCENARIO, MISSION, etc.) and the context information required.Providing basic typing of ERM messages is an advantage over TSO messages.The TSO model allows for the same message to grow as the emergency evolves and the transmission of a new type of information is required.This bears an unclear global intention for the message at any given time.

Emergency Archetypes.
Instances or specialisations of ERRM classes are devised in the form of computable and structured constraints expressed through more concrete "archetypes, " which serve as a shared language for specialised ERM messages.In other words, the ERRM encloses the stable features like the set of classes that make up the blocks constituting an ERM message and the syntax of statements, while archetypes allow for sharing a wide variety of combinations of those classes corresponding to ERM messages created for specific emergency situations.For example, "Nuclear Accident Notification, " "Tsunami Warning, " and "Oil Spill Report" are typical ERM messages that can be specified as archetypes that specialize the SCENARIO ERRM class.It is at this point where the humidity and radioactivity values mentioned above are semantically differentiated by binding them to the corresponding concept in a weather ontology or other knowledge artifact appropriated for describing the ERM domain.
In addition to TSO, there are other information models that could become the starting point for the development of the ERRM and the emergency archetypes.For example, the overview of the CESAR (Coordination of Emergencies and Tracking of Actions and Resources) model in Figure 1, described by Santos et al. [23], shows a significant increase in the variety of concepts and the semantic specificity below the second level in the hierarchy.It is precisely at that position where the two-level paradigm makes the separation between the ERRM and the emergency archetypes.
According to the requirements established in Section 2, archetypes are defined for wide reuse, but they can also be specialized to include local particularities.They can accommodate any number of natural languages, terminologies, and ontologies.Another advantage of the philosophy of twolevel modeling resides in that it allows the definition and sharing of archetypes as a decentralized process, that is, a process where repositories of archetypes are updated and maintained by a variety of cooperating groups of experts or ERM organizations, working on the same or different domains.Such flexibility supports the quick evolution of the ERM systems to deal with new kinds of disasters, pointed out in Section 2 as a problem for previous approaches.
From a more technical point of view, the two-level paradigm can be seen in this context as (i) defining a static XML schema for the three basic types of messages listed above (i.e., the ERRM) and (ii) using archetypes to define computable constraints on such ERRM and bind them to terminologies (i.e., the Archetype Model) in order to create specific ERM concepts.As a consequence, low level storage implementation can keep its heterogeneity across ERM systems while the seamless exchange of information can be achieved by developing a data mapping to the ERRM.It should be noted that this is a one-time task, as the ERRM is expected to be a static model.

Archetyping the Nuclear Accidents Information
In order to concretely explain the advantages of archetypes for the ERM domain, the information contained in the Nuclear Accident paper form in page 10 of [13] has been expressed by means of the Archetype Definition Language (ADL) (http://www.openehr.org/releases/1.0.1/architecture/am/adl .pdf),that can be automatically applied to the ERRM.The explanation focuses on the problems pointed out in Section 2, such as the semantics limitations behind sensor data.As only demonstration purposes are followed, it should be noted that the following examples are based on the openEHR Reference and Archetype Model, (http://www .openehr.org/programs/specification/releases/),with some minor modifications to adapt them to the ERM requirements.One of the purposes of the present research is to encourage further developments and acceptance of the two-level paradigm in the ERM domain.

The Archetype Definition Language (ADL).
The ADL format is divided into three sections: header, definition, and ontology.The header section (not shown in the pictures below) uniquely identifies the archetype and the ERM information involved and includes metadata about the archetype (e.g., its purpose and use).The definition section contains constraints in a treelike structure created from the ERRM.Finally, codes representing the meanings of nodes and constraints on text or terms as well as bindings to ontologies, such as BFiaO [16] and SWEET (http:// sweet.jpl.nasa.gov/ontology/),are stated in the ontology section of the archetype.It should be noted that values from the TSO dictionary could be also used in this section for backward compatibility.
For example, Code 1 contains a fragment of the definition of the Nuclear Accident archetype.The capitalized classes in lines 2, 4, 6, 8, 10, 11, 12, 15, 16, and 17 define specializations of ERRM classes such as SCENARIO in order to describe the particular constraints on the information required about the radioactive contamination.
In the ERRM, a SCENARIO instance may include information about the situation and context where the disaster has taken place.For example, sensor readings, human observations, early warnings, evolution forecasting, severity assessments, categorization of the disaster, number of casualties, postdisaster scenario update, and environmental assessment, among others.SCENARIO instances will always include a HISTORY of one or more EVENTs in order for the implementations to support the requirements described in the bullet about the history of measurements in Section 2. For example, HISTORY instances are essential in the management of nuclear plant emergencies, the time span of which is extended to years if the potential long-term consequences in health are considered.Consequently, parameters such as the radioactivity in the water supply of nearby populations must be regularly monitored once the radioactive leak has been neutralized.
As all emergency SCENARIOs require information about the disaster itself and also about the context in which they are taking place, each EVENT in HISTORY will include a data section and a context section.It should be noted that the EVENT class in the ERRM is not referring to the disaster event, but to the event of taking measures and assessing the SCENARIO.
Then the ELEMENT ERRM class is specialized inside ERRM containers such as ITEM TREE and ITEM LIST to define the constraints of a particular data value, for example, from a sensor device.Local and unique identifiers, such as at0007 in Code 2, are used to attach structural and semantic constraints to the same concept, but at different positions inside the archetype.While the content of Codes 2, 3, and 4 guarantees structural interoperability of data values, the semantics are further attached in the ontology section (see Code 5).
It should be noted that the ELEMENT Accumulated Precipitation, defined in Code 4, allows different units to be used for recording the value.Still, it is not free text at all, and further constraints such as the number of decimal positions (i.e., precision) can be also defined based on the QUANTITY ERRM class.The combination of the constraints in Code 4 with the multilingual description for at0050 in the ontology section shown in Code 5 allows preserving the semantics of the sensor data coming from the SSW.In addition, mappings to SSW ontologies such as SWEET can be established in the term bindings in order to support automatic alignment with other sources of information and to provide formal semantic descriptions.

Integrating SWRL Rules to Trigger Alerts
In addition to solving the inconveniences described in Section 2, the archetypes approach bears new opportunities for ERM systems such as the integration of alerts that support decision making.Many emergency management decisions, including the examples that will be described in the present section, are often modeled using a declarative approach, leading to an active interest in rule-based systems.However, as the currently available ERM data standards do not support rules integration, interoperability among the rule-based systems in the ERM domain is limited.
The SWRL (http://www.w3.org/Submission/SWRL/) language has evolved in the last years as a solution to increase rule-based systems interoperability from the Semantic Web perspective.It is based on a combination of OWL (http:// www.w3.org/TR/owl-features/) (Web Ontology Language) and the RuleML (http://ruleml.org/)(Rule Markup Language).In common with many other rule languages, SWRL rules are written as antecedent/consequent pair.On the other hand, a method for automatically translating archetype definitions to OWL has been recently designed and implemented by Lezcano, Sicilia, and Rodríguez [21] (It should be noted that the ADL2OWL translation method described by Lezcano et al. [21] is oriented to openEHR clinical archetypes.Nevertheless, as both the proposed emergency archetypes and the already existing clinical archetypes are based on similar Reference Model, and both workflows are designed according to the two-level approach, the modification of the translation in order to fit the ERM domain is a straightforward process.).Such research also describes, in detail, the benefits from the archetype-SWRL integration.To support rule integration and alert triggering in the ERM domain, the GANESHA (http://code.google.com/p/ganesha/)framework has been developed by Santos et al. [23], based on OWL ontologies and SWRL rules.
As a result, the architecture in Figure 2 is proposed for the semantic interoperability of heterogeneous ERM systems.It should be noted that emergency archetypes can be retrieved from a common repository or directly exchanged between peers, but the data syntax will be always based on a unique and static ERRM.
Based on the OWL version of the nuclear accident archetype discussed in Section 4, a set of SWRL rules to assess radioactive doses to the Thyroid could be defined, for example, by the nuclear emergency experts working in system A, and then reused when required for inference execution in a workflow detailed by Lezcano [24].For example, SWRL  has the expressive power to represent the following typical rules in a CBRN scenario (i) If the radioactivity dosage received by people is expected to be greater than 10 mSv in less than 2 days, then staying inside buildings is recommended.(ii) If the radioactivity dosage reaching the Thyroid is expected to be greater than 100 mGy, then iodine prophylaxis is indicated.

Conclusions and Further Work
This paper illustrates the advantages of the two-level modeling when applied to the ERM domain, paying special attention to the representation of sensor data and other kinds of magnitudes and measures coming from different sources.
The limitations of the existing formats in the ERM domain have been studied in order to justify the need of new approaches that cope with the evolution of the SSW.The proposed approach is based on a combination of emergency archetypes (to provide flexible semantic descriptions and constraints over the ERM data) and an ERRM to avoid the syntactic interoperability issues that may rise between heterogeneous ERM systems when sensor data and information about new kinds of disaster is exchanged.
The association of several streams of sensor data to a single disaster or emergency is another advantage of the archetypes approach, given the fact that sensor devices can be spread across near, but still different, locations in regard to the disaster, and the semantic descriptions provided by SSW are not designed to attach a given set of sensor data to a particular event.Having all the information centralized International Journal of Distributed Sensor Networks in an emergency archetype, which is defined for every specific type of disaster, is a significant step towards the semantic interoperability of ERM systems and the decision making support.Furthermore, the reusability supported by the proposed codification of ERM information allows for the planning of actions accounting for available resources and other contextual circumstances.
A year after the nuclear accident of Fukushima, it has been acknowledged that some erroneous decisions were made during the evacuation of nearby residents.A more proper and fast reaction to overcome the accident was in part inhibited by the lack of complete, precise, and coherent information about the meteorological and radioactive conditions in the affected area.According to the New York Times, residents of the nearby town of Namie were evacuated after the accident to the northern town Tsushima, believing that winter winds would be blowing south and carrying away any radioactive emissions.In fact, the winds had been blowing directly toward Tsushima, making the evacuated personal highly exposed to the radioactive plume (http://www .nytimes.com/2011/08/09/world/asia/09japan.html).Avoiding such kind of inaccurate ERM decisions is an expected outcome of the semantic interoperability that can be achieved between ERM systems when applying the approach described in this paper.
It should be noted that there are some concerns about ERM messages, such as versioning and sender identification, which were not discussed in the present paper and will be addressed in further work.Defining provenance constraints over the accident information will be also in the focus of future work.

Figure 1 :
Figure 1: The dotted line represents the boundary between the ERRM and the emergency archetypes when applying the two-level paradigm to the CESAR model.

Figure 2 :
Figure 2: Two-level architecture for the semantic interoperability of ERM systems.

Table 1 :
Comparison of temperature and concentration data representation between SWE, TSO, and CAP.name xlink : href="http : //sweet.jpl.nasa.gov/ontology/property.owl#Temperature"/> <om : value xsi : type="gml : MeasureType" uom="Cel">22.3</om: value> Code 1: Fragment of the definition section of the nuclear accident archetype designed to achieve semantic interoperability when exchanging the information in the paper-based form introduced in Section 2.