Sage Journals: Discover world-class research

Abstract

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.

1. 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 large-scale, 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/osiris_en.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/Santa_Mar%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/CWA_15931-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.oasis-open.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.

2. 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 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.

2.1. 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 all-hazards, 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 know-how 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.

Table 1

Comparison of temperature and concentration data representation between SWE, TSO, and CAP.

< o m : NamedValue >	SWE
< om $:$ name xlink : href=“http : //sweet.jpl.nasa.gov/ontology/property.owl#Temperature”/>
< om : value xsi : type=“gml : MeasureType” u om=“Cel”>22.3</om : value >
</om : NamedValue >

< om : NamedValue >
< om : name xlink : href=“http : //sweet.jpl.nasa.gov/ontology/property.owl#SubstanceConcentration”/>
< om : value xsi : type=“gml : MeasureType” u om=“ppm”>30</om : value >
</om : NamedValue >

< WEATHER >	TSO
TMP + 22
</WEATHER >

< NAME >
Toxic area − concentration = 30 ppm
</NAME >

< parameter >	CAP
< valueName > Temperature </valueName >
< value>22.3 Cel</value >
</parameter >

< parameter >
< valueName > Concentration </valueName >
< value>30 ppm</value >
</parameter >

(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/EnvironmentalRadiation/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.

3. 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.

3.1. 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.

3.2. 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.

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.

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 two-level 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.

4. 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.

4.1. 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.

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.

(1) definition

(2) SCENARIO $[$ at0000 $]$ matches { - - Nuclear accident

(3) data matches {

(4) HISTORY $[$ at0001 $]$ matches { - - Event Series

(5) events cardinality matches {1⋯2} matches {

(6) EVENT $[$ at0002 $]$ occurrences matches {0⋯1} matches { - - Early Warning

(7) data matches {

(8) ITEM _TREE $[$ at0003 $]$ matches { - - Tree structure

(9) items cardinality matches {0⋯*} matches {

(10) CLUSTER $[$ at0004 $]$ occurrences matches {0⋯1} matches { - - Categorization

(11) ELEMENT ${\dots}$

(12) ELEMENT ${\dots}$

(13) ⋯

(14) context matches {

(15) ITEM _ LIST $[$ at0013 $]$ matches { - - Weather Conditions

(16) ELEMENT ${\dots}$

(17) ELEMENT ${\dots}$

⋯

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).

Code 2: Specialization of the D ATE_TIME ERRM class to define [at0007]: Category Declaration Time.

ELEMENT $[$ at0007 $]$ occurrences matches {0⋯1} matches { - - Category Declaration Time

value matches {

DV_DATE_TIME matches {

value matches {yyyy-mm-ddTHH : MM : SS}

⋯

Code 3: Specialization of the O RDERED ERRM class to define [at0018]: Pasquill Category.

ELEMENT $[$ at0018 $]$ occurrences matches {0⋯1} matches { - - Pasquill Category

value matches {

$1 ∣ [$ local :: at0019 $]$ , - - A

$2 ∣ [$ local :: at0020 $]$ , - - B

$3 ∣ [$ local :: at0021 $]$ , - - C

$4 ∣ [$ local :: at0022 $]$ , - - D

$5 ∣ [$ local :: at0023 $]$ , - - E

$6 ∣ [$ local :: at0024 $]$ , - - F

$7 ∣ [$ local :: at0025 $]$ - - G

⋯

Code 4: Specialization of the Q UANTITY ERRM class to define [at0050]: Accumulated Precipitation.

ELEMENT $[$ at0050 $]$ occurrences matches {0⋯1} matches { - - Accumulated Precipitation

value matches {

C_DV_QUANTITY <

list = <

$[$ “1” $]$ = <

units = <“mm”>

$[$ “2” $]$ = <

units = <“l/m^∧2”>

⋯

Code 5: The semantic descriptions and mappings to ontologies, terminologies, and other knowledge artifacts in the ERM domain can be established in the ontology section of the archetype. Multilingualism and human readable descriptions are supported in this section.

ontology

term_definitions = <

$[$ “en” $]$ = < items = <

$[$ “at0000” $]$ = <

text = <“Nuclear accident”>

description = <“Notification of Nuclear Accident or Incidence in NPP”>

…

$[$ “at0007” $]$ = <

text = <“Category Declaration Time”>

description = <“Time at wich the category was assigned”>

…

$[$ “at0015” $]$ = <

text = <“Wind Speed”>

description = <“15 minutes wind speed average, represented in km/h”>

$[$ “at0016” $]$ = <

text = <“Altitude”>

description = <“Altitude at which the wind speed was measured (m)”>

$[$ “at0017” $]$ = <

text = <“Wind Direction”>

description = <“Wind Direction – Azimuth”>

$[$ “at0018” $]$ = <

text = <“Pasquill Category”>

description = <“Value from the Pasquill-Turner Stability Index”>

$[$ “at0019” $]$ = <

text = <“A”>

description = <“Extremely Unstable”>

$[$ “at0020” $]$ = <

text = <“B”>

description = <“Unstable”>

…

$[$ “at0027” $]$ = <

text = <“Liquid”>

description = <“Liquid Precipitation”>

…

$[$ “at0039” $]$ = <

text = <“Thyroid”>

description = <“Doses to the Thyroid from at a distance of 3, 5 and 10 kms, represented

in Sv”>

…

$[$ “at0050” $]$ = <

text = <“Accumulated Precipitation”>

description = <“Accumulated Precipitation after 15 mins and represented eitherin mm or

in l/m^∧2”>

…

$[$ “es” $]$ = < items = <

$[$ “at0000” $]$ = <

text = <“Accidente Nuclear”>

description = <“Notificación de Accidente o Incidencia Nuclear en Planta Nuclear”>

…

$[$ “at0007” $]$ = <

text = <“Hora Categoría”>

description = <“Hora de declaración de la Categoría”>

…

$[$ “at0050” $]$ = <

text = <“Precipitación Acumulada”>

description = <“Precipitación acumulada en 15 mins y expresada en mmol/m^∧2”>

…

term_binding = <

$[$ “BFiaO” $]$ = < items = <

$[$ “at0000” $]$ = $< [$ “http://www.ieru.org/ont/emergency/events#Nuclear” $] >$

…

$[$ “SWEET ontology” $]$ = < items = <

$[$ “at0007” $]$ = $< [$ “http://sweet.jpl.nasa.gov/ontology/property.owl#Time” $] >$

$[$ “at0015” $]$ = $< [$ “http://sweet.jpl.nasa.gov/ontology/property.owl#Speed” $] >$

$[$ “at0016” $]$ = $< [$ “http://sweet.jpl.nasa.gov/ontology/property.owl#Altitude” $] >$

$[$ “at0017” $]$ = $< [$ “http://sweet.jpl.nasa.gov/ontology/space.owl#Azimuth” $] >$

$[$ “at0027” $]$ = $< [$ “http://sweet.jpl.nasa.gov/ontology/substance.owl#LiquidWater” $] >$

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.

5. 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.

Figure 2

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

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.

6. 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 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.

References

Gross

The Earth Will Don an Electronic Skin

BusinessWeek, 1999, http://www.businessweek.com/1999/99_35/b3644024.htm

Compton

Henson

Lefort

Neuhaus

Sheth

A survey of the semantic specification of sensors

Proceedings of the 2nd International Workshop on Semantic Sensor Networks (SSN' 09)

2009

17 32

Pschorr

Henson

Patni

Sheth

Sensor discovery on linked data

Proceedings of the 7th Extended Semantic Web Conference (ESWC ′10)

2010

Babitski

Bergweiler

Hoffmann

Schön

Stasch

Walkowski

A. C.

Ontology-based integration of sensor web services in disaster management

5892

Proceedings of the 3rd International Conference on GeoSpatial Semantics (GeoS ′09)

December 2009

103 121 Lecture Notes in Computer Science

Le Phuoc

Hauswirth

Linked open data in sensor data mashups

Proceedings of the 2nd International Workshop on Semantic Sensor Networks (SSN ′09)

2009

Sheth

Henson

Sahoo

S. S.

Semantic sensor web

IEEE Internet Computing 2008 12 4 78 83

2-s2.0-47649100253

10.1109/MIC.2008.87

Heiler

Semantic interoperability

ACM Computing Surveys 1995 27 2 271 273

10.1145/210376.210392

Compton

Barnaghi

Bermudez

García-Castro

Corcho

Cox

Graybeal

Hauswirth

Henson

Herzog

Huang

Janowicz

Kelsey

W. D.

Le Phuoc

Lefort

Leggieri

Neuhaus

Nikolov

Page

Passant

Sheth

Taylor

The SSN ontology of the W3C semantic sensor network incubator group

Journal of Web Semantics 2012 17 25 32

10.1016/j.websem.2012.05.003

Berners-Lee

Bizer

Heath

Linked data—the story so far

International Journal on Semantic Web and Information Systems 2009 5 3 1 22

2-s2.0-77952649961

10.4018/jswis.2009081901

10.

Barnaghi

Presser

Moessner

Publishing linked sensor data

Proceedings of the 9th International Semantic Web Conference

November 2010

11.

Havlik

Schimak

Denzer

Stevenot

Introduction to SANY (sensors anywhere) integrated project

Proceedings of the 20th International Conference on Informatics for Environmental Protection

2006

12.

Raape

Teßmann

Wytzisk

Steinmetz

Wnuk

Hunold

Strobl

Stasch

Walkowski

A. C.

Meyer

Jirka

Konecny

Bandrova

T. L.

Zlatanova

Decision support for tsunami early warning in Indonesia: the role of OGC standards

Geographic Information and Cartography for Risk and Crisis Management 2010

Berlin, Germany

Springer

233 247

13.

Martínez-de-Angulo

L. F.

RIESGO TECNOLÓGICO NUCLEAR (Situación en España)—Plan de Emergencia Nuclear (Central Nuclear de Almaraz)

Conferencia Internacional De Protección Civil

2010

http://cipc2010.ipcb.pt/MicrosoftPowerPoint1.pdf

14.

THALES-Communications

OSIRIS—Open architecture for Smart and Interoperable networks In Risk management based on In-situ Sensors. Consolidation Report

2009

15.

De Maio

Fenza

Gaeta

Loia

Orciuoli

A knowledge-based framework for emergency DSS

Knowledge-Based Systems 2011 24 8 1372 1379

2-s2.0-80051472787

10.1016/j.knosys.2011.06.011

16.

Sicilia

M.-Á.

Santos

Main elements of a basic ontology of infrastructure interdependency for the assessment of incidents

5736

Proceedings of the 2nd World Summit on the Knowledge Society: Visioning and Engineering the Knowledge Society. A Web Science Perspective

2009

533 542 Lecture Notes in Computer Science

17.

Botterell

Addams-Moring

Public warning in the networked age: open standards to the rescue?

Communications of the ACM 2007 50 3 59 60

2-s2.0-34147126419

10.1145/1226736.1226767

18.

Beale

Archetypes, constraint-based domain models for future-proof information systems

Proceedings of the 11th Workshop on Behavioral Semantics: Serving the Customer (OOPSLA ′02)

2002

16 32

19.

Elstein

A. S.

Shulman

L. S.

Sprafka

S. A.

Medical Problem Solving: An Analysis of Clinical Reasoning 1987

Cambridge, Mass, USA

Harvard University Press

20.

Fiedrich

Burghardt

Agent-based systems for disaster management

Communications of the ACM 2007 50 3 41 42

2-s2.0-34147178163

10.1145/1226736.1226763

21.

Lezcano

Sicilia

M.-A.

Rodríguez-Solano

Integrating reasoning and clinical archetypes using OWL ontologies and SWRL rules

Journal of Biomedical Informatics 2011 44 2 343 353

2-s2.0-79952748773

10.1016/j.jbi.2010.11.005

22.

Lezcano

Sánchez-Alonso

Sicilia

M.-A.

Associating clinical archetypes through UMLS metathesaurus term clusters

Journal of Medical Systems 2012 36 3 1249 1258

10.1007/s10916-010-9586-9

23.

Santos

Sicilia

M.-A.

Padrino

Ontologies for emergency response: effect-based assessment as the main ontological commitment

Metadata and Semantic Research 2011 240 93 104 Communications in Computer and Information Science

24.

Lezcano

Combining ontologies and rules with clinical archetypes [Ph.D. thesis] 2011

Alcalá de Henares, Spain

Department of Computer Science, University of Alcalá

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

Abstract

1. Introduction and Motivation

2. Limitations of Current ERM Formats for Representing Sensor Data

2.1. Limitations of TSO and CAP

3. Two-Level Modeling of Emergency Management Information

3.1. The Emergency Response Reference Model (ERRM)

3.2. Emergency Archetypes

4. Archetyping the Nuclear Accidents Information

4.1. The Archetype Definition Language (ADL)

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.

Code 2: Specialization of the D ATE_TIME ERRM class to define [at0007]: Category Declaration Time.

Code 3: Specialization of the O RDERED ERRM class to define [at0018]: Pasquill Category.

Code 4: Specialization of the Q UANTITY ERRM class to define [at0050]: Accumulated Precipitation.

Code 5: The semantic descriptions and mappings to ontologies, terminologies, and other knowledge artifacts in the ERM domain can be established in the ontology section of the archetype. Multilingualism and human readable descriptions are supported in this section.

5. Integrating SWRL Rules to Trigger Alerts

6. Conclusions and Further Work

References