Keywords

1 Introduction

Common standard interfaces allow data communication among disparate systems. By complying with a standard interface, each system can exchange data with every other compliant system. Otherwise the interoperability of the systems can be quite challenging, technologically complex, time consuming and expensive. Emergency management is a multi-discipline domain where effective management of crises and disasters requires communication of different organizations in different domains such as government, health, media, and military. Although each of these domains has its own well-established standards, not all emergency responding parties conform to the same set of standards, which creates a crucial interoperability challenge. Furthermore, standards have many optional fields and different versions. Even if only one standard is used by two different systems, interoperability of them can still be problematic due to misinterpretation of optional fields or usage of different versions [1].

Semantic Interoperability has been an active research and development area in various domains such as eHealth and eBusiness. There are several completed and ongoing work in these domains for the semantic interoperability of electronic documents. OASIS Semantic Support for Electronic Business Document Interoperability (SET) TC [2] is one of them and its basic idea is to explicate the semantics of different but overlapping electronic business document standards as ontologies and then provide semantic mediation among these ontologies. OASIS SET TC approach has been proven to be useful and effective in several studies such as iSURF project, where a Semantic Interoperability Service Utility were developed by following this approach for the exchange of supply chain planning information documents [3].

In order to solve the interoperability problem, in European Commission supported C2-SENSE project [4] which aims to develop a profile based Emergency Interoperability Framework by the use of existing standards and semantically enriched Web services, we take this engineering approach and apply it to the emergency management domain to implement semantic mediation mechanisms to be able to harmonize information conforming to different but overlapping emergency standards. In this regard, in this paper, we present a Semantic Interoperability Suite which enables the information exchange between emergency management domain applications through a central layer instead of one-to-one transformations between several different content models, by developing a common ontology. Common Data Elements (CDEs) that have been elicited within this study underpin the common ontology which can be considered as the semantic dictionary of the interoperating applications.

2 Technology Description

2.1 Standards

The Emergency Data Exchange Language (EDXL), developed by OASIS International Open Standards Consortium, is a suite of XML-based messaging standards that facilitate emergency information sharing between government entities and the full range of emergency-related organizations [5]. EDXL standardizes messaging formats for communications between these parties. EDXL includes several individual standards, that are Common Alerting Protocol (EDXL-CAP), Distribution Element (EDXL-DE), Hospital AVailability Exchange (EDXL-HAVE), Resource Messaging (EDXL-RM), Reference Information Model (EDXL-RIM), Situation Reporting (EDXL-SitRep), Tracking Emergency Patients (EDXL-SitRep).

The Common Alerting Protocol [6] is an XML-based data format for exchanging public warnings and emergencies between alerting technologies. CAP allows a warning message to be disseminated simultaneously over many warning systems to many applications.

Distribution Element [7] is used as a container that facilitate the routing of any properly formatted XML emergency message to recipients.

EDXL-HAVE [8] is a document format for exchanging information on status of a hospital, its services, and its resources such as bed capacity, service availability etc.

Resource Messaging [9] defines specific message types supporting the major communication requirements for allocation of resources across the emergency incident life-cycle.

EDXL-SitRep [10] is an XML-based data format for transmitting timely available situation reports, incident or event information, and operational picture.

In much the same way that HTML and HTTP standards enable the exchange of any type of information on the Web, The Open Geospatial Consortium’s (OGC) Sensor Web Enablement Initiative (SWE) [11] is focused on developing standards to enable the discovery of sensors and corresponding observations, exchange, and processing of sensor observations, as well as the tasking of sensors and sensor systems.

2.2 ISO/IEC 11179, Semantic Metadata Registry and IHE Data Element Exchange

ISO/IEC 11179 is an international standard developed with the aim of providing a metadata-driven data exchange in heterogeneous environments. Combining principles of semantic theory and data modelling, the standard defines the representation of metadata in a metadata registry [12].

In our study, we employ an ISO/IEC 11179 compliant Semantic Metadata Registry (MDR) to maintain metadata of data elements (e.g. location, alert, observation) and communicate with it via the IHE Data Element Exchange (DEX) profile, which we authored [13]. DEX provides a standardized way of querying data element metadata, and allows dynamic mappings between data elements such as EDXL data elements to their OGC equivalents when complemented with extraction specifications (e.g. XPATH, SQL scripts) maintained in Semantic MDR.

3 Methodology and Implementation

During the implementation of Semantic Interoperability Suite, first information domain has been carefully analysed and following standards corresponding to emergency management have been identified as relevant [14].

  • EDXL-SitRep (Situation Reporting)

  • EDXL-RM (Resource Messaging)

  • EDXL-HAVE (Hospital Availability Exchange)

  • EDXL-TEP (Tracking of Patients)

  • EDXL-CAP (Common Alerting Protocol)

  • OGC SensorML (Sensor Modeling Language)

  • OGC O&M (Observations and Measurements).

The common ontology has been created based on the knowledge that was gained as a result of this analysis. In this regard, first a number of Common Data Elements (CDEs) which can be considered as ontology resources have been defined and stored in Semantic MDR. CDEs are the smallest meaningful data container in a context. They can be regarded as the semantic dictionary of the interoperating application.

Figure 1 illustrates an example decomposition of a CDE which refers to birth date information of a person. As shown in the figure, the concept of the CDE and the representation are separate in the metamodel. In the given example, “Person” is the Object Class and “Date of Birth” is the property together which constitute the concept of “Person.DateOfBirth”. This is the concept of the data element regardless of its representation. The other main concepts for which CDEs are defined can be listed as address, location, resource, report, alert, and observation (sensor measurement). After CDEs are defined, a common ontology in OWL (Web Ontology Language) format is generated by following the OASIS SET TC approach.

Fig. 1.
figure 1

An example of decomposition of a Common Data Element: Person.DateOfBirth.Date

Full size image

In the next step, standard content models listed above have been mapped to the common ontology via extraction specifications so that data represented in one standard format can be converted to another. Extraction specifications are for locating relevant data element in the corresponding standard content model. As all current standards are XML based, extraction specifications are defined as XPATH queries in our system. Table 1 below presents three different extraction specifications of EDXL-SitRep, EDXL-CAP and OGC-O&M standards for “LocationByCoordinates.Latitude” data element.

Table 1. Data element and extraction specifications
Full size table

C2-SENSE Semantic Interoperability Suite enables domain experts to define extraction specifications only once, then the conversion between content models is done automatically according to these specifications. It is possible to define extraction specifications for any number of standard content models. There is no need to make an update on the system, when specifications for a new content model is going to be added.

Overall architecture of C2-SENSE Semantic Interoperability Suite is illustrated in Fig. 2. In Semantic Interoperability Suite, a Semantic MDR Tool is provided to users as a graphical user interface (GUI) to facilitate the definition of CDEs and extraction specifications. Semantic MDR Tool can be considered a web-based metadata management and data modelling tool to create and maintain CDEs collaboratively either based on imported standard content models or from scratch [15]. Given a standard format, it is able to list the data elements included in it; given the data element list, it can also provide mappings of elements to a specified target standard format.

Fig. 2.
figure 2

Architecture of C2-SENSE Semantic Interoperability Suite

Full size image

Semantic Mediator is the component in Semantic Interoperability Suite fulfilling the duty of converting data represented in one standard to a data represented in another standard. This functionality is satisfied thanks to Semantic MDR and IHE DEX profile. When the system receives a request of conversion, it fetches common ontology (in other words CDEs) and corresponding extractions specifications from Semantic MDR using DEX profile. If the source and target content models are available in the registry, e.g. EDXL-SitRep as the source and OGC-O&M as the target, conversion is done automatically by Semantic Mediator according to pre-defined extraction specifications. Semantic Mediator is provided to outside world through a RESTful API.

4 Example Usage

In C2-SENSE project, an Emergency Domain Interoperability Framework, which Semantic Interoperability Suite is part of, has been developed. This framework has been validated by a realistic flood scenario in Puglia region of Italy. In this section, we present an example usage of Semantic Interoperability Suite in this scenario.

It has been raining in Puglia region for several days and the sensors located near Fortore river measures the water level exceeding the threshold value. Therefore, Regional Functional Center of Puglia is alerted and emergency plan for flood situation is started to be applied. As part of this plan, people living near flood area is evacuated, houses, healthcare services and equipment are provided, some roads are blocked and volunteers are involved to follow the situation on field. Meanwhile, a car accident occurred at the 15th km of “Strada Statale 100”. Immediate intervention of Fire Brigade is required. Therefore, Innova Puglia, who is the technology provider of Civil Protection Service of Puglia Region, alerts Fire Brigade regarding the accident. Fire Brigade system uses the EDXL-CAP as the data format and Innova Puglia system is able to produce message in this format. Hence, the following XML message (for the sake of simplicity, namespaces have been removed in the XML messages) is generated by Innova Puglia and sent to Fire Brigade successfully with no additional effort.

figure a

After Fire Brigade receives the alert message, it needs to inform corresponding local authorities about the situation, and this message should be sent in EDXL-SitRep format. However, Fire Brigade system is only able to produce and retrieve messages in EDXL-CAP format. A solution to this problem could be updating the Fire Brigade system so that it can support exchanging documents in EDXL-SitRep format as well. However, this requires a lot of work and is impossible to do during the emergency situation. Instead of this, Fire Brigade uses the Semantic Interoperability Suite of C2-SENSE system to convert the EDXL-CAP message presented above to EDXL-SitRep message automatically. The result of this operation is the following XML.

figure b
figure c
figure d

In technical point of view, for instance, in CAP message, latitude and longitude information is provided in “/cap:alert/cap:info/cap:area/cap:circle” element (see Table 1). In order to present this information in SitRep message, Semantic Mediator of Semantic Interoperability Suite performs following actions:

  1. 1.

    Retrieve CDEs and extraction specifications from Semantic MDR.

  2. 2.

    Find the corresponding Common Data Element for the XPATH “/cap:alert/cap:info/cap:area/cap:circle”, that is LocationByCoordinates.Latitude.characterstring.

  3. 3.

    Find the corresponding XPATH definition of SitRep for this Common Data Element, that is “/element(*,ResourceDetailType)/reportToLocation/ct:EDXLGeoPoliticalLocation/ct:geoCode/ct:value”.

  4. 4.

    Place the information.

5 Conclusion

In order to manage crises effectively, interoperability of different systems using dispersed standards is crucial. One way to provide interoperability among these systems is to update the existing software so that one system can generate messages in all the desired formats. It is obvious that this requires a lot of work and should be done for every single system. In this regard, C2-SENSE Semantic Interoperability Suite is a powerful mechanism since it enables organizations to make such conversions between emergency domain standards automatically without making any updates on their own systems.

Currently, C2-SENSE Semantic Interoperability Suite is able to make conversion among EDXL-SitRep, EDXL-RM, EDXL-HAVE, EDXL-CAP, OGC SensorML and O&M standards. Feasibility and usability of the system is currently being tested in a realistic flood scenario in Puglia Region of Italy within the scope of C2-SENSE Project.