Information Conceptualization for Emergency Management

PROMETEO EMSOA 2010 International Workshop on Emergency Management through Service Oriented Architectures

Information Conceptualization for Emergency Management Ouejdane Mejri Politecnico di Milano

Outline

! ! ! ! !

 Context  EMISs requirements   Process modeling  Ontologies for EMISs  Conclusion

2

Emergency Management Information Systems (EMISs)

!  Emergency Management Information Systems (EMISs), usually employed in the Emergency Operation Rooms provide a set of ICT tools for supporting the emergency management process during its entire lifecycle: §  Mitigation and preparedness §  Response §  Recovery

3

Monitoring and Emergency management workflow (MIARIA project)

Monitoring process

Emergency management process

4

Babel tour

5

Information flow in emergency preparedness processes

6

Monitoring natural hazards (landslides example)

Communication activities during pre-alarm situations

Necessity: Dynamicity in Contingency

!  In multi-hazard and multi-risk scenarios, the collection of disaster agent-generated requests changes as time passes from the time of impact §  requests associated with initial impact may

decline while new demands arise from secondary threats.

!  These changes occurring over time may be associated to information and/or operation management needs.

7

Flexibility and configurability

!  On the one side, crisis and risk management requires a flexible EMIS architecture, easily customizable, to support people on the field by considering the actual characteristics of the disruptive event that has occurred. !  This architecture needs to involve the adoption of emergent technologies, such as lightweight and highly configurable multiagent systems, service oriented solutions in mobile environments, or ad-hoc sensor networks.

8

Enriched Information management

9

!   On the other side, it is fundamental to have an enriched information management that allows §  the collection, §  the classification §  and the extraction of data

throughout the overall amount of information inflowing into the entire workflow. !   Such information regards data present in: §  “Historical” contingency plans §  Data coming from sensor networks, external EMISs, and data

gathered from external and not-supervised data sources as Web sites and Social Networks.

SOAs for emergency management !   The EMIS needs to be re-designed with respect to the new requirements and the lack of flexibility requires some effort to re-design and re-implement the workflow that supports the evolving contingency plan !   Service Oriented Architectures could facilitate §  the definition of contingency scenarios (preparedness stage) §  the adaptation of various scenarios in order to generate a realistic

emergency plans involving different EMISs (emergency stage)

!   This type of architecture separates the infrastructure from the provided services. As a consequence, all the EMISs installed in the EOCs could be considered as members of a peer-to-peer network where each node provides a set of services and can potentially communicate with all the others.

10

Emergency management workflow analysis

Information

11

Process Modeling

risk assessment and Emergency management process composition

12

Sub-processes Modeling

13

Conceptualization of information

!  We propose to encode the information flow existing into the contingency management workflow in order to: §  Create a shareable knowledge about the likely

exploited information and its use during the whole process §  Support components and functions of EMISs

!  The potential use of this ontology: §  supporting not only singularly the activities of

emergency planning, response and recovery but also the entire workflow

14

Related work !   Several works were developed in the last years relatively to the use of ontologies in contingency handling §  focusing exclusively on the emergency response process

!   These formal disaster ontologies were proposed to §  Enhance an effective communication by defining a

common set of vocabularies §  Generate event notifications and facilitate system accessibility §  Create a decision support system from existing emergency documents and use cases §  provide a great flexibility to extend into a mission-oriented ontology

15

Related work

16

!  Interoperability data standards attempt to provide data interoperability through standardizing messages and data elements (e.g. Common Alert Protocol (CAP) and Emergency Data Exchange Language (EDXL)) !  Disaster Taxonomy through a sociological viewpoint

Factual knowledge !   Our analysis of information flow into contingency management workflows will be related to the domain factual knowledge providing knowledge about its objective realities !   We analyze the §  §  §  § 

information objects, their properties, states and inter-relations over time

in the contingency global process and its sub-processes identifying operational information exchanges between various parties, i.e., interdependencies between them

17

Information source

18

!   Various modeling techniques, such as Unified Modeling Language (UML) or Entity-Relationship (ER) were used during the project to represent different viewpoints of the systems, such as functional view or logical view respectively. !   A complete picture of the domain was obtained §  Theories and applications for emergency management

literature (i.e., Sociology, Organization and Information Systems) §  Domain experts addressed the ambiguities and gaps in information through questionnaire and interviews

Ontology Development

19

!   We choose to develop as a first step a domain ontology through a taxonomy, i.e., tree structure of classifications for a given set of objects (containment hierarchy) !   The degree of granularity of the ontology needs to be §  generic and application independent as possible for share-

ability and interoperability §  expressive as possible to define a precise conceptualization

!   The next step will consist of adding the relationships related to communication interactions §  Who communicated what and when?

Part of the ontology: disaster consequence

20

Ontology sample: disaster consequence

21


First emergency Response

22


First emergency Response Second emergency Response

23


Emergency Response Emergency Recovery

24

Information classification: injury object !   Severity i.e., lethal, severe, moderate, mild. !   Cause of injury §  Relatedness to natural disaster •  Unrelated •  Indirect •  Direct

§  Structural relatedness •  •  •  •  • 

Structural Non-structural Contents Infrastructure None

§  Secondary hazards … §  Injury mechanism …

!   Treatment §  Level §  Immediacy

!   Etc.

25

Further work : Ontology completion and evaluation

26

!  To assess the quality of design, we will consider the principles from §  software engineering (i.e., abstraction, modularity,

separation of concerns, generality, anticipation for change, and rigor and formality) §  ontological criteria (i.e., construct overload, construct redundancy, construct excess, and construct deficit)

!  To assess the coverage of concepts and the ease of understanding of the ontology, we will consider doing it through questionnaire and interviews with multidisciplinary users

Conclusion

!  Practically speaking, this conceptualization is unlikely to cover all possible potential uses in the contingency management and does not imply any commitment to implementing a related knowledge system. !  However it may be more appropriate, than ad hoc information modelling, for designing flexible EMISs, particularly when they pursue Service Oriented Architecture’s (SOA) design.

27