Data interoperability software solution for emergency reaction in the Europe Union

Emergency management becomes more challenging in international crisis episodes because of cultural, semantic and linguistic differences between all stakeholders, especially first responders. Misunderstandings between first responders makes decision making slower and more difficult. However, spread and development of networks and IT-based emergency management systems (EMSs) have improved emergency responses, which have become more coordinated. Despite improvements made in recent years, EMSs have not still solved problems related to cultural, semantic and linguistic differences which are the real cause of slower decision making. In addition, from a technical perspective, the consolidation of current EMSs and the different formats used to exchange information offers another problem to be solved in any solution proposed for information interoperability between heterogeneous EMSs in different contexts. To overcome these problems, we present a software solution based on semantic and mediation technologies. EMERGency ELements (EMERGEL) (Fundacion CTIC and AntwortING Ingenieurbüro PartG, 2013), a common and modular ontology shared by all the stakeholders, has been defined. It offers the best solution to gather all stakeholders’ knowledge in a unique and flexible data model, taking into account different countries’ cultural and linguistic issues. To deal with the diversity of data protocols and formats, we have designed a service-oriented architecture for data interoperability (named DISASTER: Data Interoperability Solution At STakeholders Emergency Reaction) providing a flexible extensible solution to solve the mediation issues. Web services have been adopted as specific technology to implement this paradigm that has the most significant academic and industrial visibility and attraction. Contributions of this work have been validated through the design and development of a cross-border realistic prototype scenario, actively involving both emergency managers and emergency-first responders: the Netherlands–Germany border fire.


Introduction
Emergency management involves several actors who must interact in order to prevent risk or to coordinate their activities to react to hazardous situations (González-Moriyón and Rubiera, 2012).This interaction mainly implies the interchange of information to provide a quick and integrated response to the threatening event.Time is the number-one quality parameter (Swersey, 1994) not only because swiftness appears to be reasonable in an emergency situation but also because time can be measured far more easily than other possible quality parameters (Swersey, 1994).The authors of this paper have extensive experience in operational emergency management as well as emergency planning.The experience as well as interviews with practitioners during the DISASTER (Data Interoperability Solution At STakeholders Emergency Reaction) project shows that sharing information and coordination between international workforces and dealing with a large amount of information in a highly dynamic environment is one of the most challenging tasks in emergency management.This is due to the fact that decision makers operate in a given framework of reference in which they Published by Copernicus Publications on behalf of the European Geosciences Union.
are trained, allowing them to make quick, efficient and effective decisions (Muhren and Van de Walle, 2010).Enabling interoperability between different systems -both technical and cultural -allows decision makers to make sense of a situation in their own terms of references and enables swifter, more effective and more efficient emergency management.DISASTER aims to enable and improve the interoperability between systems.
In order to manage and share critical information, dedicated information and communication technology (ICT) systems, usually known either as emergency management systems (EMSs) or crisis information management systems (CIMSs), have emerged.A list of acronyms is given in Table 1.
In the member states of the EU, each stakeholder has deployed its own system of command, control and communication.As a direct result of this situation, EMSs and information data models and formats are invariably incompatible with each other, meaning that cooperation between emergency forces becomes almost impossible in many situations (Currás, 2012).Moreover, in an international context, the situation with regard to the EMS-to-EMS exchange of information provides a number of challenges, considering not only technical interoperability (data formats, models and communication protocols) but also diversity in language (e.g. in Europe 28 member states with more than 24 official working languages), background and cultural particularities (e.g.metric system), methodology or structure (diversity of organizational structures starting at local level), legal issues (different regulation, complex legal landscape) or data representation (myriad colour codes, different graphical symbol sets), among others.To address these challenges a twofold solution is proposed in this article: the development of a common and modular ontology shared by all the stakeholders, taking into account different countries cultural, semantic and linguistic issues (named EMERGEL;Fundacion CTIC and Antwort-ING Ingenieurbüro PartG, 2013), and, from that point, the implementation of transparent service-oriented architecture (SOA) providing mediation algorithms compliant with current data formats and existing solutions (named DISASTER).
Of course this approach is a bottom-up approach trying to integrate different emergency management systems, both technical and cultural.Another approach would be a top-down one by simply standardizing all emergency management operations and the cooperation between agencies throughout the EU.This top-down approach has several disadvantages.First of all there is the language barrier across most of the EU's inner borders.Standardizing terms would mean a harmonization by translation and thus an automatic fallback to a worse translation solution than translating via a knowledge base.Second, emergency management works most effectively and efficiently if there is a certain level of standards but also flexibility to react individually on a local, regional or national level.Standard operating procedures such as the German DV 100 reflect this by offering a frame- work to work in but allow decision makers to adapt to a situation.Third, the bottom-up approach is a slow but effective integration process especially in terms of acceptance of a system.By choosing a bottom-up approach the overall system can learn from practitioners and also allow them to keep their own frameworks and terms of reference.However, it also enables learning from each other so that a slow but effective harmonization process can take place (Groskopf, 2012).Main roles (users) involved in the proposed solution can be termed the silver command or tactical command level of a rescue operation.Even gold level decision makers can benefit from our solution since translation and mediation need to take place on both the vertical and the horizontal axis.Vertical here means the exchange of information between operational units on the same hierarchical level; vertical means the exchange of information across hierarchical levels (reports up, orders down).However, since most organizations have established effective hierarchical methods to distribute information; errors and misunderstandings are harder to identify on the horizontal axis.
The mentioned users take advantage of using our software interoperability solution to exchange data with other sections or other organizations within the same operation following existing models (Vickery and Vickery, 2004).The requirements taken into account in our research were identified by interviews to stakeholders and emergency experts as well as the authors' team member own experience and reinforced by survey results.The mentioned survey was conducted via an online tool.In total 60 experts from fire brigades, ambulance services and other related agencies completed the survey.Detailed results on the requirement analysis can be found in Schütte and Weber (2012).
Since this work aims to create an interoperability solution for the emergency management sector, the issues connected with and to be addressed during the development need to be split into technical issues that need to be solved within the software and non-technical issues that need to be solved with the software.
The technical issues that need to be solved are the keystone of our contribution.The main areas of interest here are format and protocol as well as data representation.Format and protocol issues, or in other words syntactical interoperability, are the basis of all communication between systems.This communication can take place either by standards or by message mapping to convert the data.It is necessary to identify in which cases which solution is suitable.However, message mapping might be the more suitable solution for complex concepts that need to be transferred like units or vehicle types.Although the translated terms especially of vehicles, but also of unit types (e.g.fire engine or ambulance), suggest that the named objects are capable of doing the same tasks in an operation, this is not necessarily the case.For example the German emergency medical services know of at least three different vehicle types that can all be translated to the word "ambulance".Vehicles and units operate as parts of a management system that is in the best case a national one, but also regional management systems exist (e.g. the German fire services know 16 different laws for fire protection according to the 16 federal states).A plain translation or standardization is thus not suitable to satisfy the different complex management structures.These data need serious interpretation by the user to be understood and put into a correct context and reference frame (Muhren and Van de Walle, 2010).It is important that such a reference frame is crucial for the sense-making process of the decision maker.Only such a reference frame created by training and repetition of situations and concepts allows the decision maker to decide fast.
Therefore a plain translation of terms is not suitable.Rather, these data need to be translated also in terms of underlying concepts.Understanding of the situation comes with a suitable representation of the transferred data.The most comprehensive form to represent relevant data in a rescue operation is the common operational picture (COP), which can be seen as the concrete form of the framework of reference of a particular operation.The DISASTER + EMERGEL pro-posed solution will be able to transfer the needed data to create such a situational map.In this context geo-referencing is important for the system to correctly place units and other items on the map if the map is created by the system out of different pieces of information (Köhler et al., 2006).Understanding of a situation needs to be created by transferring the underlying concept of the data to the receiver.It is necessary to do this in a very structured way so that no information is erased or created without recognizing it.Translation tools as mentioned above can help to achieve this goal.However, it is necessary to know that most of these issues can only be solved by technical means.In contrast to the syntactic issues, this type of issues can be summarized as semantic issues.
The last aspects to mention are cultural and organizational differences between the organizations that like to exchange information.While cultural differences hinder the understanding of the information since the concepts and the framework of reference are different, the organizational differences might hinder the very data exchange.Cultural differences can be solved by implementing solutions for the semantic issues mentioned above.This means the more different the (EMS) culture, the more translation work needs to be done.The final goal of the proposed solution is to create understanding of a situation by different stakeholders.Therefore the nontechnical interoperability issues are of great importance.
The rest of the paper is structured as follows.Section 2 overviews the general solution composed by DISASTER and EMERGEL.Section 3 presents EMERGEL, the ontology innovation to achieve the semantic integration of resources.Section 4 defines the DISASTER architecture and its implementation details.Validation of the contributions is presented in Sect. 5 through the design and execution of a realistic prototype scenario actively involving both emergency managers and emergency-first responders: the Netherlands-Germany border fire.A discussion of the results is also presented in this section.Finally, Sect.6 concludes the paper.

Technical solution overview
This section aims to give an integrated vision of the software solution as a whole system, its inputs and outputs and its functionality.Further details about the design and implementation of the two main components EMERGEL and DIS-ASTER are presented in Sects.3 and 4 (Fig. 1).
DISASTER software plays the role of intermediary between different systems that need to collaborate.It is in charge of receiving original data and sending the mediated information to the final destination.DISASTER's main capabilities include data format and protocol transformation.Not only technical adaptations are required, but also conceptual adaptation is usually needed.That is the objective of EMERGEL.EMERGEL is an ontology that supplies semantic mediation between emergency-related concepts.EMERGEL provides an application programming in- terface (API) that is consulted by DISASTER in order to execute the whole transformation process.
DISASTER architecture follows the SOA principles (Sahin and Gumusay, 2008).Using this approach, it provides the capability of using a single resource through its published service and not directly addressing the implementation.This loose coupling allows changes to the implementation by the service provider should not affect the service consumer.Web services (WSs) can implement SOA; they are self-contained and self-describing; and they can be published, located and dynamically invoked providing interoperable machine-to-machine iteration over a network and an open-extensible solution (Weerawarana et al., 2005).
The DISASTER system is designed as a network of mediator components and a central element (core) that provides functionality to the rest of participants as shown in Fig. 1.DISASTER core is the kernel of the system and provides functionality that is shared by involved mediators, making their implementation easier and uniform.The core component is a WS where the functionality is separated into WS operations.Mediators are gateways between specific EMSs and resources.Each mediator relies on DISASTER-core-exposed services to perform its tasks.Mediators are also WSs providing to each EMS an interface to use the whole DISASTER solution.
The EMERGEL ontology is the main source of information, well-structured to support the mediation.It mainly supports emergency situations within a common and modular ontology capable of being exploited by all the stakeholders dealing with such emergency situations.The ontology has been tailored manually by consortium emergency experts and automatically published thanks to the mediation software infrastructure.As one of the final results of this work, this ontology can be exploited by different players in different forms.First, the mediation component consumes EMERGEL mappings to perform specific translations.
Next, the EMERGEL API adds a REST WS1 layer to enable a lightweight query functionality that is already being consumed by the DISASTER solution.

The EMERGEL ontology
This section presents EMERGEL (EMERGency ELements), a new context-dependent ontology defined by experts to provide semantic mediation services for emergency-related concepts.EMERGEL plays a main role in the software solution for data interoperability proposed in this work.It has been made publicly available at Fundacion CTIC and AntwortING Ingenieurbüro PartG (2013).
An emergency situation is a natural, man-made or technological hazard resulting in an event of substantial magnitude causing significant physical damage or destruction, loss of life, drastic change to the environment or simply damage to property.From a security point of view, disasters can be seen as the consequence of inappropriately managed risks, which are the product of a combination of both hazards and vulnerability.That kind of events stem from other events such as earthquakes, floods, catastrophic accidents, fires or explosions.That is why the concept of "event" is pivotal in the modelling of the ontology, as will be duly noted in the following paragraphs.
The EMERGEL ontology development process is driven by broad-scope questions, as well as by the competency questions (González-Moriyón and Rubiera, 2012) defining the coverage of the data model to be built: -What -the ontology interprets a disaster as a kind of event.Therefore, EMERGEL reuses the class dul:Event from the upper-level ontology DOLCE (University of Trento n.d.).Furthermore, and to specify that generic event class, the ontology builds upon existing emergency incident classifications widely used in security domains, such as insurance, freight transport and critical infrastructures (ports, airports etc.).These classifications have been adapted and merged to fit the modelling requirements identified in a set of competency questions handed to the domain-expert partners from the DISAS-TER project to enclose the scope of the ontology.
-Why -events are liable to cause other events.A simple landing operation of a plane can lead to an incident like an airplane crash in an airport.Additionally, this accident may have direct and collateral consequences such as a fire, chained explosions, a chemical accident in a neighbouring industrial facility, a full airport closure etc.To semantically capture the causality chain between the diverse events in a given disaster, the property emergel:causes (and a set of companion subproperties) were added to the ontology.
-Where and when -the proper spatio-temporal contextualization of a disaster is crucial to ensure successful information exchange among stakeholders.The ontology provides a means to temporally describe a crisis situation in RDF2 .This is a critical problem as information changes over time and, in particular, with respect to space.For instance, the damaged surface due to a forest fire is not the same at the beginning of the conflagration as 2 days afterwards.The EMERGEL approach is based on a 4-D (four-dimensional) view of reality, sometimes called a perdurantist perspective, and builds upon previous work of tOWL (Milea et al., 2012)  The design of EMERGEL is divided into three main modules (Fig. 2): a core ontology, which is a supple lightweight vocabulary focusing exclusively on events and agents.This core module however is combined as well with a second transversal module dealing with time and space.Finally, the third module (vertical modules) is designed to host in the form of concept schemes any relevant vocabulary able to assist the core module.These vertical modules enable browsing those modules by means of an ad hoc viewer (called SKOSI Ć; Fundacion CTIC, 2014) as a thesaurus for "human beings" and not only being exploited by the DISASTER API as a machine.They are thematically split into eight clearly differentiated spaces: -"Companies": companies/enterprises potentially involved in an emergency situation, such as harmed parties (airlines, ferry lines etc.), vehicle or goods manufacturers or as involved agents in that situation.
-"Places": places and locations in a broad sense that are relevant in such situations -continents, geographical areas, countries and their subdivisions, country associations, aerial regions, airports, power stations, bodies of water etc.
-"Vehicles": vehicles potentially involved in incidents as victims or as agents assisting in such situations.Under this category a wide number of codes used by international organizations to identify them are included.
-"Dangerous goods": dangerous goods and substances, including symbols and pictogram used to represent them.
-"Emergency symbols": graphical icons, symbols and pictograms used by different countries and/or organiza- tions to represent emergency situations, agents, POIS etc. from a tactical point of view.
-"Third-party vocabularies": standard vocabularies relevant for an emergency situation used by external organizations.EMERGEL provides mappings between concepts, aligning in this way EMERGEL with these vocabularies.
-"Standardization organizations": organizations that standardize products, technologies, codes etc. and that own some of the symbol sets and codes used in other theme sections of EMERGEL.
-"EMSs": a list of emergency management systems used by diverse organizations to address this type of events.

Vertical modules development methodology
The vertical modules are designed to ease the interaction between domain experts and ontology engineers.To that end, emergency domains (i.e.vertical modules) were formalized collaboratively between the ontology engineers (with strong experience in OWL-based modelling) and the domain experts who have collaborated in this work.The initial approach was based upon a number of competency questions prepared by the ontology engineers to be addressed by the domain experts.The answers to these competency questions (González-Moriyón and Rubiera, 2012) were the cornerstone of the first steps to model the ontology.There are a number of non-ontological resources at national and European levels that are of EMERGEL interest.For instance, regarding crisis data representation in a given cartography, there exist different symbologies used in the European landscape.These differences pose a hindrance to interoperability in both international cross-border cooperation and national coordination of stakeholders.EMERGEL aims to incorporate these in-use schemes (taxonomies, data catalogues, cartographic symbologies and so forth) into a common representation format, i.e.RDF, to enable the specification of semantic equivalences to drive data translation processes between IT crisis management systems.
There are a number of options to specify these mappings between knowledge resources, ranging from heuristic-based semiautomatic generation to manual definition by experts.The former is more of a research topic that might not guarantee accurate results.The latter is backed by the knowledge of an expert.Moreover, these manual alignments can be validated by the experts' community.Given the strong domain knowledge in the project where this work has been carried out, it was reasonable to design a manual methodology to successfully involve consortium security experts in the ontology development loop.
This methodology is a three-step workflow, defined as follows: Fig. 3 shows a particular example of a translation between a Dutch map symbology and a German map symbology: 1. Taxonomy creation and mapping specification -the domain expert encodes original non-ontological resources and specifies correspondences between them in the form of a table that is specially formatted for further automatic processing.
2. Automatic generation of SKOS taxonomies and RDF mappings (EMERGEL vertical modules) -the taxonomies and classifications are automatically encoded in SKOS/OWL.The previous correspondences are automatically extracted from the table and converted to mappings defined in a technical format, i.e.SKOS vocabulary to taxonomies alignment.
3. Execution of mappings -the mappings are available online as part of the EMERGEL ontology.They are used on demand by the mediation component to perform a given data translation process.
In order to allow third-party applications to access the ontology, an API has been defined and called "EMERGEL API".The EMERGEL API is available as REST services following the general DISASTER architecture approach.In addition, this API includes an SPARQL6 endpoint interface to access the ontology directly.Technical documentation is detailed in Tejo-Alonso et al. ( 2013) and González-Moriyón and Tejo-Alonso (2014).The reference implementation of EMERGEL API REST services has been developed using Play Framework 2.1.1.The web application that contains the services is deployed over an Apache Tomcat/7.0.26 using Java 1.6.024-b24.

The DISASTER software architecture
This section describes the architecture of the DISASTER solution but also presents the technologies used to implement the whole system.The WS platform has been chosen as a technical paradigm due to its loosely coupled, standardbased approach for building SOA solutions.-Adapters: once the data is in RDF format, several mediation processes are executed to transforms data expressed in a given format according to a given data scheme and available through a given protocol, into equivalent data in possibly different format, schema and protocol.
-Resources: resources in DISASTER are defined as a catalogue of geospatial information services compound of data about geolocated features represented primarily by images and tables or grids of observed or calculated attributes.This family of services allows publication, management and subscription of resources.
The other key component in the DISASTER architecture design is the mediator.A DISASTER mediator is a gateway between a concrete EMS and the rest of the existing resources.
There are two kinds of mediators: -Input mediators allow an EMS to consume external resources adapted to its own style.
-Output mediators allow sharing information to other EMS.
Mostly mediators are input mediators since the most common problem for an EMS is to be able to understand external information.Note that both solutions are non-intrusive for the existing applications.Figure 5 summarizes the set of WS specifications that DIS-ASTER will adopt in its implementation.This set of standards, called the Disaster Technical stack, is not a random walk through a space of WS specifications but rather an organized, structured architecture with well-defined designs to fulfil the technical requirements (Casado et al., 2012c).
The Disaster Technical stack is divided into six levels according to the nature of the included WS standards.The bottom level is transport, which refers to the message format and protocols used to exchange the information.Description level includes the standards to describe both functional and non-functional characteristics of the services.Discovery level refers to the standards used to publish and organize the services included in the DISASTER solution.Messaging level refers to the mechanism provided to ensure that messages are correctly delivered to the appropriate destination.Quality of service (QoS) level focuses on the reliability and security of the interactions.Finally, Cooperation level deals with the composition and coordination between multiple service operations when required (Casado et al., 2012).As briefly introduced in Sect.2, the DISASTER solution is a network of components (mediators) and a central component (core).The core provides a set of functionality to the mediators making their implementation easier and uniform.That functionality includes data adaptation, data mediation and resource management.In terms of implementation, the core exposes a WS interface where the functionality is split into concrete WS operations.Each mediator is a gateway between a concrete EMS and the rest of the existing resources.It allows consuming information from external sources but presenting such data adapted to the concrete EMS characteristics.The mediator relies on the services provided by the core to perform the majority of its activities.In terms of implementation, the mediator is a WS client that interacts with the core, but also it is a WS itself providing an interface to the EMS to use the whole DISASTER solution.As depicted in Fig. 1, each EMS has to be related to mediators.There are two types of mediators according to each their behaviour: -Output mediator: it is the simplest kind of mediator and basically plays the roles of listener and server.In other words, an output mediator detects when a new resource has been created and/or updated in an EMS and makes it available for the rest of DISASTER components.The actions carried out by the mediator depend on the specific source EMS but usually include format adaptation, temporally hosting and resource serving.
-Input mediator: it allows consuming information from external sources while presenting such data adapted to the concrete EMS characteristics.These characteristics refer not only to technical issues (e.g.formats and protocols) but also to cultural and linguistic preferences and tactical values of resources.The mediator relies on the services provided by the DISASTER core to perform the majority of its activities such as data format adaptation or the resources management and in the EMERGEL solution to solve the semantic interoperability.
The mediator components allow the EMSs to use external information transformed to their own protocols, formats and cultural and linguistic characteristics.The main task of mediators is to handle the EMS requests.-Semantic-based mediators are in charge of executing the mapping between different data schemas.In order to execute this mapping, the EMERGEL REST API is consumed.Further details about EMERGEL were presented in Sect.3.
Resources component allows EMSs to publish their operational picture maps.Non-geospatial information such as mediation issues, roles and permissions are also managed by the DISASTER resources component.

Validation
A scenario-based design is followed by the authors to validate their contributions.The test scenario is a key element in this approach, whose purpose is to verify that the DISAS-TER architecture plus the EMERGEL ontology has the potential for real-world application.Real EMSs such as LCMS (Landelijk Crisis Management System; LCMS, 2010), for the Dutch side, and DISMA (DISaster MAnagement; TUV Rheinland n.d.), for the German one, are used in the evaluation.These EMSs are briefly introduced in Sect.5.3.We selected these two concrete EMSs for practical purposes: members of the consortium in charge of executing this research had access to and knowledge of these two software applications.In addition, both EMSs have already been used in the Netherlands and Germany.The Netherlands-Germany border fire use case was designed and executed to provide a realistic test situation, and it is based on a proven history of needs for interoperability of EMSs.The planned scenario aims to bring together the key stakeholders, the technologies on which they depend and the middleware solutions from DISASTER + EMERGEL to demonstrate the potential for improved interoperability.

Scenario history: border fire
The information for this scenario was provided mainly by the fire department of the city of Bocholt (Germany) and collected during interviews with the operational command staff of the fire department of the city of Bocholt.In addition, the operational report of the Dutch operation was reviewed to create the scenario.This report is not publicly available.
In June 2011, a peat fire in the cross-border region between Enschede (NL) and Ahaus/Gronau (DE) occurred that involved 130 ha of protected bog and heathland.Around 350 fire officers from the two countries were manually cutting into burning ground to access the deep fire layer for water treatment.These officers had to move across an area where the heat could suddenly approximate a furnace.Ministry level collaboration provided thermal imaging from helicopters to show high-risk areas, but systems on each side of the border were not interoperable, and so these images could only be accessed by some of the operatives on the ground.Commanders from Veiligheidsregio Twente (NL) and from the North Rhine-Westphalia (DE) were challenged in specifying exactly where men were positioned, and they found it difficult to share information about progress or to ask for assistance.Text and radio message exchange was not sufficient due to missing interoperability.Even files could not be exchanged easily since the security settings of PCs did not allow an exchange of files via flash drives.Subsequent analysis suggests a need for shared map information, with added (tagged) layers showing first responder placements of personnel and vehicles, supported by translation of terminology (common ontology).
The meaningful (semantic) cross-border exchange and presentation of information required to ensure safety includes geographic information (GI), metadata and attribute data supported by a reliable middleware translator/transformer.

Test objectives
In response to the observed features of the above-referenced historical scenario, the authors conducted realistic proof-ofconcept testing whereby a cross-border COP can be generated as shown in Fig. 6.The figure shows that in the Netherlands the COP is map-based, with icons showing personnel and vehicle deployment, and it stops at the Dutch border.The same is true for the German COP.The elements can be combined using the DISASTER + EMERGEL solution as shown in final image.
The proposed use case scenario and test event involved assembling a set of first responders, vehicles, ancillary equipment, communications etc. in a suitable location so as to allow commanders and staff to use the interconnectivity of our innovative solution to enrich their COP.The intention is that they will command and observe movement of personnel and vehicles at different parts of the exercise field, will make continuous adjustments to the situation (as per their normal exercise activities) and as a consequence will see the changes from both sides of the "virtual border" propagated across to ensure a cross-border COP as illustrated previously (Erden and Coşkun, 2010).

Test setup
The planned test event was conducted in December 2012 and located at Twente Airport near Enschede, the Netherlands.The test was planned as part of the annual national security exercises which use this military site, and this allowed all of the mentioned stakeholders to be present.Vehicles with transponders fitted will appear on maps automatically since they are already tracked that way, and personnel will be placed on maps by having local team commanders report position information in the normal way via the active EMSs.
Commanders were allowed to continually make adjustments to personnel and vehicle position data in the EMS within the parameters of their normal exercise activities, and both they and the authors were able to continually observe activities via an enriched display, as observed from all stakeholders.
The airfield is surrounded by some woodland in that area and so is shrouded by trees.By positioning vehicles in such a way that they could not see each other, the scenario was able to show commanders in different groups/vehicles exchanging crisis management information they cannot acquire without collaboration.LCMS is an EMS used by 20 of the 25 public safety and security regional authorities in the Netherlands.It can be regarded as the National EMS for the Netherlands.At operational level there is a single national communication network for police, fire brigades and the first-responder teams.LCMS viewer provides a specific interface for each emergency role and makes a link with the central database of emergency response room (ERR) systems.It also provides a reporting tool where all activities during an incident are logged.
DISMA is a software application developed for executive staff in emergency management.It is used by the silver level in large-scale incidents and provides functionalities such as plotting the incident locations, placing icons over a map, working with more than just one map at the same time etc.Unlike the Netherlands, Germany does not use homogeneous software for emergency management.DISMA is just one of the EMSs used in Germany.
In order to standardize the geospatial information generated in the DISMA XML-based own format, a MediatorOutput has been developed whose main goal is to convert the exported information into ESRI SHP format and then send the file to DISASTER core services so that this mediation can be shown through EMERGEL.
The necessity for the format transformation (XML to SHP) is due to DISASTER using Geoserver as the GIS (geographical information system), which stores the whole geospatial information provided by the different mediators.All medi-ators use DISASTER core components to transform the exported information provided by the different EMSs into SHP.

Test results: discussion
From a functional point of view the results showed that an improvement for decision making in an emergency situation with the support of the DISASTER solution is possible.Two aspects form the improvement from a functional perspective: 1.The fact that an interoperability solution for EMS enables a fast exchange of information enables a quicker decision-making process.Information can be transferred directly without using extra technology.In the specific case of the test the decision makers could use their own situational maps and did not have to meet and discuss since the information was available immediately.
2. Presenting the exchanged information in the EMS in a way the viewer or user is used to seeing (like the national EMS symbol standard) quickens the process of understanding the situation and thus also leads to faster decision making.Not every piece of information needs to be explained in meetings anymore.In the specific case of the test the number of meetings was significantly reduced compared to other tests the authors had witnessed in the past.Decision making went smoothly and effectively, and the situation was solved quite fast.This is often not the case in such a situation.In many cases in the past the decision makers were caught in a discussion circle, sometimes about a rather irrelevant aspect of the situation.
Since time is the number-one quality parameter in emergency situations (Swersey, 1994) both aspects have direct impact on the quality of the emergency response.Given the modular approach, the DISASTER core and mediator components ensure that new EMS can be added to the system easily and thus will enable a quick adoption of the solution.
However, the technical nature of the solution leads to several challenges related to information exchange that could also be observed during the test.Since the information is presented in the particular viewer's context of understanding, it is necessary that accuracy in the translation and mediation process are made known to the viewer.If the information cannot be translated directly, this leads to either a lack or an increase of information.For example, the term "fire engine" implies a basic understanding of the use of such vehicle, but also very specific differences in understanding for decision makers from different countries.Next to the technical solution of making changes to the information obvious by adding a warning symbol and an overview of the changes, it is also important that each user of the system is able to train the use on a regular basis.These guidelines are being developed to allow future users to understand the use of the DISASTER solution and to design effective training scenarios.Finally, with DISASTER being a technical solution, there needs to be an implementation phase before the system can be used.The test showed that this implementation phase needs to involve serious testing and also training of the users so that information is readily available when needed.
This was also the conclusion of a research-practitioner workshop that was organized in January 2014 in Bocholt (DE).60 participants from fire departments from the Dutch-German border as well as several researchers discussed the details of the DISASTER solution during this workshop.
From a technical point of view, the results showed the viability of the proposed architecture to deal with the mediation requirements.Besides the linguistic, tactical and operational differences, some technical issues also have to be addressed.The German brigade publishes the map on a WFS server.On the other hand, the Dutch emergency system only accepts the WMS servers.As commented in Sect.2.4, it implies different levels of mediation: -cultural mediation: to use different icons to represent the same concept; -protocol mediation: to allow using WMS protocol when no export mechanism is provided.
Figure 7 depicts the sequence diagram for the border fire scenario according to the DISASTER + EMERGEL architecture.Firstly, the German fireman creates the map using his brigade's own EMS system.This map is published on its WFS server.At this time, the Dutch fireman wants to get the updated information from the German side.The Dutch fireman uses his brigade's own EMS (called LCMS as the real system) to connect to the German WFS server.But the LCMS does not work with WFS servers, so the DISASTER solution is needed.Instead of connecting directly to the German server, the LCMS connects to its mediator (called Medi-atorDutch), which is implemented as a WS.MediatorDutch consults with the DISASTER core the list of available resources.The German WFS server is included in the available resources, which means that the information from this server can be mediated.MediatorDutch, using the information provided by the DISASTER core, contacts to the MediatorGerman, which is in charge of the linguistic mediation from German context to the DISASTER ontology concepts.The mediation is completed following the next steps: 1. MediatorDutch requests the WFS map (GML format).
2. MediatorGerman gets the local DISMA XML data, transforms them to GML and publishes the final information to the DISASTER resources component.
3. By using the DISASTER Core GML2RDF adapter, Me-diatorGerman transforms the GML in RDF according to the DISASTER ontology.5. MediatorDutch, by using the DISASTER core RDF2PNG adapter, generates a valid PNG according to the set of icons used by the Dutch response teams.
6. MediatorDutch generates a valid WMS response message and returns it to the LCMS.
7. After the mediation process explained above, the Dutch fireman can see the German map in his own EMS system and according to the local context.

Conclusions
EMSs are able to provide support in terms of easy access to new and existing information and quick communication with personnel on site and remotely.However, it is necessary to provide the information in a way that respects the situation a decision maker is in.First of all this means providing the information in a way that is compliant with the decision makers' way of making sense of and understanding the situation, for example by using his national EMS symbol set.
The DISASTER solution is able to provide such support and thus contributes to the solution for the mentioned challenges.
Improving the decision-making process and thus quickening the time in which effective response actions are carried out will lead to a better operation outcome and a higher quality of rescue services.
The proposed solution based on DISASTER software architecture and EMERGEL ontology aims to provide a mechanism so that different EMSs can interoperate during the management of crisis scenarios.The solution is based on two main concepts: (i) the use of semantic technologies supporting the goal of a shared and semantically unambiguous information basis across organizations and (ii) the SOA paradigm to allow the collaboration between systems of a different nature.The scope of EMERGEL include 25 EU countries as well as further vertical modules as can be consulted in Fundacion CTIC and AntwortING Ingenieurbüro PartG (2013).
A set of WS standards are tailored to implement the DIS-ASTER service-oriented architecture.This stack will ensure the achievement of functional (e.g.specific data formats or communication protocols) and non-functional (e.g.security and policies) requirements.The network of mediators and the central component are the means to allow DISASTER to be an extensible and scalable project.By using standard specifications, both in architecture implementation and on the data management side, the implementation will provide the desired interoperability.For example the definition of a common format such as RDF simplifies the transformations, translations and enrichment of the data regardless of the initial or final format.Regarding the architecture, the use of WS standards as a communication platform will facilitate the in-tegration of new users who will take advantage of every module implemented before.The devised software solution has been validated through the development of a proof of concept and tested by experts, showing the viability of the proposed innovation.Although the scenario implemented for validating purposes only required unidirectional communication, the DISASTER software architecture can deal with bidirectional communication so that the stakeholders can take actions in real time.
DISASTER + EMERGEL is the result of an EU Seventh Framework Program-funded research project.Future works, in collaboration with EU stakeholders, include the adaptation of these improvements in more scenarios.

Figure 1 .
Figure 1.High-level overview of DISASTER software architecture.Each EMS is connected to its Mediator.DISASTER core provides generic functionalities to all EMSs.

Figure 2 .
Figure 2. High-level overview of the EMERGEL components, their transverval modules to be used in any domain and domain-specific modules (e.g.fire).

Figure 3 .
Figure 3. Processes involved in symbology translation applied to situational information maps for emergency responders.

Figure 4 .
Figure 4. DISASTER software technical architecture.The DISASTER core is the kernel of the proposed technical solution.It provides a set of functionality to the mediators making their implementation easier and uniform.A DISASTER Mediator is a gateway between a concrete EMS and the rest of the existing resources.Input mediators allow an EMS to consume external resources adapted to each one's own style.Output mediators allow sharing information to other EMS.

Figure 4
Figure 4 presents a top level of the technical architecture.The DISASTER core is the kernel of the proposed technical solution.It provides a set of functionality to the mediators making their implementation easier and uniform.The services offered by the core are organized into three families according to their nature:

Figure 5 .
Figure 5. DISASTER technical stack.The bottom level is transport, which refers to the message format and protocols used to exchange the information.Description level includes the standards to describe both functional and non-functional characteristics of the services.Discovery level refers to the standards used to publish and organize the services included in the DISASTER solution.Messaging level refers to the mechanism provided to ensure that messages are correctly delivered.Cooperation level deals with the composition and coordination between multiple service operations when required.

Figure 6 .
Figure 6.Combining German and Dutch common operational pictures (cross-border COP).

Figure 7 .
Figure 7. Sequence diagram for the border fire scenario.

Table 1 .
Acronyms used in the paper.
The mediator components in charge of dealing with EMS requests are called handlers.DISASTER solution implements handlers for the most common data type and protocols such as Web Feature Service (WFS) (WFS, 2010) and Web Map Service (WMS)(WMS, 2006)requests.New handlers can be implemented whenever necessary, due to the loosely coupled nature of the solution.The handler receives the EMS request, gets the requested information as GML (GML, 2007) from the DIS-ASTER resources component and by using the proper EMS mediator translates the concepts.If a format or protocol adaptation is required, the handler does the transformation using DISASTER core services and responds with the mediated information.A key element in the semantic mediation is the use of the EMERGEL component that is totally transparent for the involved EMSs.