d4.4. ontology model for the episecc use case 4_deliverable_report.pdfepisecc_wp4_d4...

EPISECC_WP4_D4 4_Deliverable_Report.docx 119 |1

www.episecc.eu

D4.4. – Ontology model for the

EPISECC use case

Grant agreement number: 607078 Date of deliverable: 2016-04-30

Date of project start: 2014-06-01 Date of submission: 2016-06-15

Duration of project: 36 months Deliverable approved by: AIT

TCCA

Lead Beneficiary: UNIST

Contributing Beneficiaries: AIT, HITEC, DLR, HWC, FRQ, TCCA, KULeuven

Establish Pan-European Information Space to Enhance seCurity of Citizens

http://www.episecc.eu/


www.episecc.eu

Executive Summary

The deliverable provides detailed description of the Ontology model for the EPISECC use case

including methodology, model design and validation.

The methodology explains three levels of ontologies and their usage. Upper ontologies describe

common concepts across a wide range of human domains and domain ontologies narrow the scope

to the particular domain such as medicine or computer science. The EPISECC Ontology model is an

application ontology and it serves particular task or a software application. The method used for the

ontology construction can be summarized in two steps. The first step is the modelling of the

application knowledge, when experts define basic concepts and relations among them, and axioms

together with rules for data interpretation and reasoning. During the second step the application

concepts are linked with the concepts in both reference upper and domain ontologies.

Following this approach, the ontology scope is defined firstly. The EPISECC use case narrows down

the scope of the ontology to the scenario designed for the Proof of Concept. Deliverable 6.1 “Proof of

Concept design” elaborates the scenario and this deliverable summarises the exchanged and

dynamic data from the scenario’s episodes and use cases. Thus, the scope of the EPISECC Ontology

model encompasses the situational and operational data exchanged among the organisations in the

EPISECC use case. The EPISECC Ontology models the common operational picture with dynamic

spatial information or spatio-temporal/4D data, showing the situation in affected area and locations

of resources.

Knowing the scope of the ontology, a list of key concepts is defined. For the EPISECC Ontology model,

a subset of concepts of the EPISECC Taxonomy (D4.2) is selected according to the scope of the

EPISECC use case. Besides the concepts and their hierarchy, the relationships or properties between

classes are derived. Nine directed graphs are developed and presented in this deliverable. Two

domain ontologies, A Geographic Query Language for RDF Data (GeoSPARQL) and World Wide Web

Consortium (W3C) Time, describing spatial and temporal concepts are selected and referenced. As

the reference upper level ontology, the Descriptive Ontology for Linguistic and Cognitive Engineering

(DOLCE) Lite ontology is selected and referenced too.

This deliverable describes the first implementation of the EPISECC Ontology model. Once the

conceptual model is developed and upper and domain ontologies referenced, the ontology schema

as the formalisation of the conceptual model is created. Software-interpretable constructs are

defined by formal languages Resource Description Framework Schema (RDFS) and Ontology Web

Language (OWL). The EPISECC Ontology schema is created with Protégé Desktop and the logical

consistency is checked by applying reasoning algorithms.

The second implementation and validation will be done through the Proof of concept (Tasks 6.2 and

6.3) and the final Ontology model for the EPISECC use case will be elaborated in the Task 4.5

“Lessons learned from proof of concept and validation” and delivered in the Deliverable 4.5.

An excerpt of the EPISECC Ontology model in OWL file is given in the Annex.



www.episecc.eu

Table of Content

Table of Content ...................................................................................................................................... 3

List of Tables ............................................................................................................................................ 4

List of Figures ........................................................................................................................................... 5

List of Acronyms ...................................................................................................................................... 6

1. Introduction ..................................................................................................................................... 9

2. Methodology ................................................................................................................................. 11

2.1. The EPISECC Ontology model – an application ontology ....................................................... 11

2.2. Ontology development methodology .................................................................................... 12

2.3. Formal languages and tools ................................................................................................... 15

3. Ontology model ............................................................................................................................. 17

3.1. Ontology scope – the EPISECC use case................................................................................. 17

3.2. Ontology conceptual model ................................................................................................... 21

3.2.1. An overview of the existing ontologies ......................................................................... 22

3.2.2. Ontology model’s elements .......................................................................................... 23

3.2.3. Key concepts and their relations ................................................................................... 25

3.2.4. References to domain and upper ontologies ................................................................ 31

3.2.4.1. References to domain ontologies ................................................................................. 31

3.2.4.2. References to upper level ontology .............................................................................. 35

4. Ontology schema ........................................................................................................................... 38

4.1. Implementation in Protégé Desktop ...................................................................................... 38

4.2. Validation ............................................................................................................................... 40

5. Conclusions .................................................................................................................................... 41

Bibliography ........................................................................................................................................... 42

Annex ..................................................................................................................................................... 45



www.episecc.eu

List of Tables

Table 1: The EPISECC use case data ...................................................................................................... 20



www.episecc.eu

List of Figures

Figure 1: The ontology dimensions [4] .................................................................................................. 10

Figure 2: The ontology levels (adopted from [6]) ................................................................................. 11

Figure 3: Two-steps approach for building ontology ............................................................................ 13

Figure 4: The common operational picture data classes (adopted from [24]) ..................................... 19

Figure 5: The EPISECC Ontology model’s scope .................................................................................... 21

Figure 6: Ontology model’s main elements and their relations (adopted from [27])........................... 23

Figure 7: Example of the directed graph: generic (a) and specific one (b) ........................................... 24

Figure 8: Directed graph of the main classes and properties ............................................................... 25

Figure 9: Directed graph of the class Disaster ....................................................................................... 26

Figure 10: Directed graph of the class Process ..................................................................................... 27

Figure 11: Directed graph of the class Resource ................................................................................... 28

Figure 12: Directed graph of the class Organisation ............................................................................. 29

Figure 13: Directed graph of the class Common operational picture ................................................... 30

Figure 14: Directed graph of common operational picture containing 4D data [34] ........................... 32

Figure 15: GeoSPARQL directed graph [15]........................................................................................... 33

Figure 16: Subclasses of the class ‘Spatiotemporal part’ (adopted from [34]) ..................................... 34

Figure 17: W3C Time directed graph [16] ............................................................................................. 35

Figure 18: DOLCE basic categories of particulars [14] ........................................................................... 36

Figure 19: Directed graph of main EPISECC classes and with references to DOLCE-Lite, GeoSPARQL

and W3C Time ontology classes (adopted from [34]) ........................................................................... 37

Figure 20: Protégé Desktop interface showing imported ontologies ................................................... 38

Figure 21: Protégé Desktop interface showing the class hierarchies ................................................... 39

Figure 22 Protégé Desktop interface showing the object and data properties .................................... 40



www.episecc.eu

List of Acronyms

Abbreviation Description

BFO Basic Formal Ontology

CAP Common Alerting Protocol

CIS Common Information System

COP Common Operational Picture

DOLCE Descriptive Ontology for Linguistic and Cognitive Engineering

EMSI Emergency Management Shared Information

GeoSPARQL A Geographic Query Language for RDF Data

GML Geography Markup Language

ISO International Organisation for Standardization

LEMA Local Emergency Management Authority

OGC Open Geospatial Consortium

OWL Ontology Web Language

PPDR Public Protection and Disaster Relief

QUDT Quantities, Units, Dimensions and Types

RDF Resource Description Framework

RDFS Resource Description Framework Schema

RIF Rule Interchange Format

SKOS Simple Knowledge Organisation System

SKOS-thes SKOS extension for thesauri

SPARQL SPARQL Protocol and RDF Query Language

SQL Structured Query Language

SSN Semantic Sensor Network

SUMO Suggested Upper Merged Ontology

SWEET Semantic Web for Earth and Environmental Terminology

TSO Tactical Situation Object



www.episecc.eu

URI Uniform Resource Identifier

W3C World Wide Web Consortium

WGS 84 World Geodetic System 84

WKT Well-known text

XML Extensible Markup Language

XSD XML Schema Definition



www.episecc.eu

List of Terms

Term Definition

Concept Concepts are the units of thought or ideas, meanings, or (categories of) objects and events.

Data type properties Data type properties relate individuals to data values.

Facet A particular aspect or feature of something (Oxford dictionary).

Object properties Object properties relate individuals to individuals.

Ontology A set of concepts and categories in a subject area or domain that shows their properties and the relations between them (Oxford dictionary).

Ontology model Ontology model is a conceptual model of a domain consisting of classes, properties and individuals.

Ontology schema The description of the ontology in a formal language is named ‘ontology schema’.

Resource Description Framework (RDF) data model

RDF is a standard model for data interchange on the web (W3C).

Resource Description Framework Schema (RDFS)

RDF's vocabulary description language. RDF Schema defines classes and properties that may be used to describe classes, properties and other resources (W3C).

Reasoning algorithms A set of algorithms that use rules of logic to infer new statements from available knowledge.

Simple Knowledge Organisation System (SKOS)

A representation of knowledge organisation systems within the framework of the Semantic web.

SPARQL query language A query language for RDF.

Taxonomy A scheme of classification (Oxford dictionary).

Term Term is a label to a concept (D4.2).



www.episecc.eu

1. Introduction

A response to a critical event, as the EPISECC project’s universe of discourse, is a complex human

domain described as “a complex dynamic system composed of actions taken in a certain spatial,

technical, organisational, and legal environment during a disaster, including one or more situations

which straightforwardly lead to a disaster, as well as handing over to a recovery phase” (D4.2).

Access to information and communication with other first responders are key factors for effective

emergency operations and the current status of sharing information between the teams is not

satisfactory. The FP7 projects ACRIMAS [1] and CRISYS [2] recognised that as a major gap. The

interoperability gap is further described in the EPISECC project Deliverable 2.1 “PPDR Information

Space - Status quo of commercial, research and governmental projects and applications”. Results

revealed that more than 70% of the investigated tools reach physical and syntactical interoperability,

but only 30% (12 of 41 investigated tools) are covering the semantic interoperability. Therefore, the

EPISECC project elaborates three semantic structures facilitating semantic interoperability:

taxonomy, semantic repository and ontology model.

The backbone semantic structure is the EPISECC Taxonomy describing concepts used in “a response

to a critical event” and organizing them in hierarchies and facets (D4.2). The EPISECC Data model

provides database structure called Semantic Repository for the storage of the semantic descriptions

in the Common Information Space (CIS). The Semantic Repository stores the EPISECC Taxonomy, the

emergency organisations concepts and the semantic mappings of organisations concepts to the

EPISECC Taxonomy. The third semantic structure is the Ontology model for the EPISECC use case

(hereinafter also referred to as the EPISECC Ontology model). The EPISECC Ontology model describes

the EPISECC use case as a model of domain knowledge. The main goal is to enrich semantic

descriptions of the EPISECC Taxonomy by describing an existing situation that is highly challenging in

terms of number of agencies involved, cross-border situation and interoperability needs.

Deliverable 6.1 “Proof of Concept design” elaborates the EPISECC use case that defines a scope of the

EPISECC Ontology model. The focus of the EPISECC use case is situational awareness and definition of

the most urgent resources requested by first responders. Deliverable 6.1 defines situational and

operational data as the most important data to be exchanged and both are dynamic data including

geolocations. Therefore, the EPISECC Ontology model has main goal to model spatio-temporal data

or 4D data.

What is ontology, ontology model and ontology schema?

Ontology is the branch of metaphysics dealing with the nature of being. In the domain of computer

sciences ontologies are used for knowledge representations. Ontology is a set of concepts and

categories in a subject area or domain that shows their properties and the relations between them

(Oxford dictionary). Tom Gruber defines ontology as a formal specification of a shared

conceptualisation [3]. Today, the term ontology covers various things, from formal upper-level

ontologies expressed in first order logic such as DOLCE-Lite to the simple list of keywords used to



www.episecc.eu

annotate resources on the Web. In between the two are vocabularies and taxonomies. Ontologies

represent subsumption or ‘is-a’ relationships among entities but also other kinds of relationships

such as functional or physical. The Ontology Summit 2007 [4] has proposed so called ‘Framework’

which defines a limited number of dimensions along which ontologies can be characterized. The

Framework is comprised of semantic and pragmatic dimensions as shown on Figure 1. Semantic

dimensions include expressiveness, structure, and representational granularity. Pragmatic

dimensions include intended use, use of automated reasoning, and prescriptive versus descriptive.

Figure 1: The ontology dimensions [4]

In the context of information systems development such as CIS, the common goal of developing

ontologies is sharing common understanding of information among people or software agents [5].

Ontology model is a conceptual model of a domain consisting of classes, properties and individuals.

Classes describe concepts in the domain, properties describe relations among classes and individuals

are realisations of classes as data items. A class can have subclasses and a property can have

subproperties, thus constituting hierarchies of classes and properties.

Description of the ontology in a formal language is named ‘ontology schema’. Ontology schemas can

be compared to physical schemas or table definitions in relational database. Formal languages such

as Resource Description Framework Schema (RDFS) and Ontology Web Language (OWL) are used to

describe ontology models with software-interpretable constructs and thus to create an ontology

schema.

This report delivers the methodological approach for the development of the EPISECC Ontology

model, its content and relations to upper ontology models. The last chapter presents the EPISECC

ontology schema: a description of the EPISECC Ontology model by OWL constructs applicable to be

used by software application.



www.episecc.eu

2. Methodology

The development of the ontology model follows the methodology described in this chapter. The

overall approach includes two steps: modelling application knowledge and linking the model with

reference upper and domain ontologies. Reuse of existing ontologies should be considered as well.

The chapter starts with a brief explanation of the ontology levels, continues with the ontology

development methodology and ends with the formal languages and tools used for the ontology

development.

2.1. The EPISECC Ontology model – an application ontology

The EPISECC Ontology model is an application ontology what means that it serves a particular

software application. Figure 2 shows three levels of ontologies [6]:

upper ontologies,

domain ontologies, and

application ontologies.

An upper ontology (or foundation or top-level ontology) describes common concepts across a wide

range of human domains. There are several upper ontologies developed so far such as Basic Formal

Ontology (BFO), Suggested Upper Merged Ontology (SUMO) and Descriptive Ontology for Linguistic

and Cognitive Engineering (DOLCE). Upper ontologies are developed by philosophers and cognitive

engineers and they provide concepts and relations to domain ontologies for their merging.

Figure 2: The ontology levels (adopted from [6])

A domain ontology describes concepts of a particular human domain such as medicine, computer

science etc., and it is developed by domain experts. Domain concepts could be referenced to the



www.episecc.eu

concepts of upper ontologies and thus, the domain ontologies that use the same upper ontology can

be merged automatically. The domain of emergency management does not have a specifically

intended ontology model. Liu et al. in [7] present a comprehensive review of the ontologies for crisis

management. The review identifies a total of 11 subject areas represented in contemporary crisis

information systems including critical infrastructures, resource management, decision support,

situation awareness, response coordination, etc. but the authors state the following: “Moreover, no

formal ontologies are specifically intended for representing the emergency and disaster domain. The

existing ontologies that represent the disaster subject area are mainly in the form of database

schemas, which are not publicly available.” [7]. The World Wide Web Consortium (W3C) published

the report “Emergency Information Interoperability Frameworks” in 2009 [8]. This document

describes candidate components of the emergency management ontology based on common use

cases.

Application ontology describes concepts used by a particular software application e.g. data and

software application concepts used by a web service. Application concepts could be referenced to

the concepts of domain ontologies and the application ontologies that use the same domain

ontology can be merged automatically. Application ontologies are developed by software developers.

The EPISECC Ontology model is an application ontology serving emergency response tasks for the

EPISECC use case. Sharing situational and operational data among the first responders is considered

as the critical one for the success of rescue operations. Therefore, the focus of the EPISECC Ontology

is modelling of spatio-temporal or 4D data showing locations of the most urgent resources requested

by the first responders.

2.2. Ontology development methodology

Ontology could be built either from scratch, by reusing existing ontologies, or by modifying existing

ontologies to the application domain. There are four ontology development methodologies recently

developed: Methontology [9], On-To-Knowledge [10], Diligient [11] and NeOn Methodology [12].

Methontology is a comprehensive methodology used to build ontologies from scratch and at the

conceptual level. On-To-Knowledge methodology includes a tool environment for semantic

information processing of large numbers of heterogeneous documents and it speeds up knowledge

management in large companies. Diligent methodology is focussing on the evolution of ontologies

instead of the initial design. NeOn Methodology is a scenario-based methodology that supports the

collaborative aspects of ontology development and reuse, as well as the dynamic evolution of

ontology networks in distributed environments. Based on the above mentioned methodologies and

taking into account the specifics of spatial data, the authors Kun et al. in [13] have proposed the

method of ontology construction for spatial data combining bottom-to-top and top-to-bottom

approach in two steps as follows.

The first step (or bottom-to-top) models the application knowledge. Experts define basic

concepts and relations among them, and define axioms and rules for data interpretation and

reasoning.



www.episecc.eu

The second step (or top-to-bottom) links the application concepts with concepts in the

reference upper and domain ontologies. One should consider reuse of the already developed

ontological resources.

The above two-steps approach is selected for the development of the EPISECC Ontology model

because the approach suits the ontology scope and application level. Figure 3 shows the sources of

application knowledge for the EPISECC Ontology model:

the EPISECC Taxonomy (D4.2),

the EPISECC use case (D6.1).

The upper and domain ontologies used are the following:

Descriptive Ontology for Linguistic and Cognitive Engineering (DOLCE)-Lite (upper ontology)

[14],

A Geographic Query Language for RDF data (GeoSPARQL) (domain ontology for spatial data)

[15], and

W3C Time (domain ontology for temporal data) [16].

Figure 3: Two-steps approach for building ontology

The selected methodology for the EPISECC Ontology model development consists of the following

seven tasks.

1. Define the scope of ontology

2. List the key concepts in the selected domain/application

3. Establish the conceptual model for ontology

4. Reuse the existing ontologies and/or make references to domain and upper ontologies

5. Formalize ontology and populate it with individuals

6. Validate ontology

7. Revise and refine ontology

A brief description of the above development tasks follow.

Ontology development starts by defining its domain and scope. Answering on several basic questions

can help limiting the scope of ontology. Examples of such questions are given in [17]:

What is the domain that the ontology will cover?

For what we are going to use the ontology?



www.episecc.eu

For what types of questions the information in the ontology should provide answers?

Who will use and maintain the ontology?

The EPISECC Ontology model scope is defined by the EPISECC use case (D6.1) and described in

Chapter 3.

Knowing what is the scope of ontology, a list of key concepts and terms can be defined. Concepts are

selected if they are used in writing statements or explaining the ontology scope to a user. What are

the terms and their properties used in explanations? For the EPISECC Ontology model, a subset of

concepts and terms of the EPISECC Taxonomy (D4.2) is selected according to the scope of the

EPISECC use case.

To establish a conceptual model for ontology, classes and properties (also called relations) with their

hierarchies (or “is-a” relation) must be defined. Classes and class hierarchy are defined by the

EPISECC Taxonomy (D4.2), but properties, subproperties and property hierarchy must be derived.

Properties can be seen as four types as follows [17]:

intrinsic properties such as the capacity of a vehicle;

extrinsic properties such as a rescuer’s name;

parts, if the object is structured; these can be both physical and abstract parts (e.g., the

actions of a decontamination);

relationships between individual members of the class and other items (e.g., the owner of a

vehicle, representing a relationship between a vehicle and a organization).

Property can have other aspects such as cardinality, value type, domain, range etc. Besides classes

and properties, a conceptual model can define axioms and rules for data interpretation and

reasoning. Conceptual model for ontology is expressed as one or more directed graphs. Additional

descriptions such as domains and ranges are documented by a text coupled with the directed graphs.

Conceptual model of the EPISECC Ontology model is described in Chapter 3.

Many ontologies are already available and there are libraries of reusable ontologies (also called

design patterns) on the Web such as Ontology design pattern Web portal [18]. It is worth considering

existing work and checking if this can be refined and extended to suit the scope of new ontology. In

case that an application ontology needs to interact with other applications, their ontologies must be

considered and referenced. The common way to merge application level ontologies is by referencing

them to the same upper and domain level ontologies. The EPISECC Ontology model is an application

level ontology and there are no existing ontologies to be reused, but there are existing domain and

upper ontologies to which the EPISECC Ontology is referenced.

Once the conceptual model is developed and upper and domain ontologies selected, the ontology

schema can be created and populated with individuals. Ontology schema is a formalisation of the

conceptual model. Software-interpretable constructs are defined by formal languages RDFS [19] and

OWL [20], the W3C standards. The ontology schema of the EPISECC Ontology model is described in

Chapter 4.

The next step is to populate ontology schema with test data describing individuals, the instantiations

of classes. The EPISECC Ontology model will be populated with test data through the Proof of



www.episecc.eu

Concept (Tasks 6.2 and 6.3). The test data will reflect the EPISECC use case and will be collected

during the field exercise.

The final step is to validate ontology schema. Logical consistency of an ontology schema is checked

by applying reasoning algorithms. The schema is not consistent if reasoning algorithms infer that one

individual belongs to two disjoint classes. Ontology modelling is subjective work of an expert and

there is a need for an objective way to validate the model. The most common approach is to create

test use cases and a list of related competency questions or questions the model should answer

correctly [21]. The EPISECC Ontology model implementation and validation will be done along with

CIS functions design. The validation will include end users and project’s Advisory Board members as

planned within WP6 through the Proof of Concept (Tasks 6.2 and 6.3). The Proof of Concept scenario

describes data exchanged between actors and data needed by responders. Therefore, based on the

Proof of Concept scenario and use cases, a list of competency questions will be built. The ontology

model will be validated through its ability to answer the competency questions.

Ontology development is an iterative process. The first version of ontology is revised and filled with

more details according to validation results, thus the final EPISECC Ontology model will be elaborated

in Task 4.5 “Lessons learned from proof of concept and validation” and delivered in the Deliverable

4.5.

There are many modelling decisions to be made during the ontology development process. Whether

to model a specific distinction (such as human, financial and material resources) as a property value

or as a set of classes? Whether a particular concept is a class in an ontology or an individual instance

of a class? e.g. shell ’water tank truck’ be represented as a class or as an instance of the class

‘vehicle’? The decisions should be based on criteria which solution would work better for the given

tasks, be more extensible and maintainable. Ontology as a model of reality must contain concepts

which reflect this reality. The first version of developed ontology must be evaluated by using it in

applications and discussing it with users and experts. This iterative process will continue through the

entire lifecycle of the ontology.

2.3. Formal languages and tools

RDFS and OWL are W3C standard languages for formal description of RDF database and ontology

schema. The EPISECC Data model and the EPISECC Ontology model are formalised by RDFS and OWL.

Although already described in Deliverable 4.3 “Data model”, the main characteristics of RDFS and

OWL are given briefly as follows.

RDFS and OWL are based on RDF vocabulary that defines Subject, Predicate and Object, which

constitute Triples, the building blocks in RDF database [21].

The RDFS language has a small set of constructs and rules [19]. The constructs are the following:

definitions of classes and hierarchy between classes via sub-classes,

definitions of properties and hierarchy between properties via sub-properties, and

definitions of domain and range describing relationships between classes and properties.



www.episecc.eu

OWL extends RDFS with many modelling constructs such as: operations over sets (union,

intersection, complement), cardinality, characteristics of properties (inverse, symmetric, reflexive,

functional, transitive), restrictions, etc. [20]. The key construct of OWL is a restriction, which

describes classes by restricting the values allowed for certain properties. A combination of RDF, RDFS

and OWL constructs can be used to model complex relationships between classes, properties and

individuals.

The EPISECC project consortium decided to use open source tools for both data model and ontology

development and implementation. The Protégé Desktop [22] tool is selected for ontology schema

development because it supports RDFS and OWL languages and includes reasoning algorithms used

for ontology schema consistency checking. Protégé Desktop is described in detail in the deliverable

D4.2 “Taxonomy model”.



www.episecc.eu

3. Ontology model

This chapter explains the conceptual model of the EPISECC Ontology consisting of classes and

properties. Following the methodology described in Chapter 2, the scope of the ontology is defined,

the key concepts are selected, and the ontology model is established and explained. According to the

defined scope, the EPISECC Ontology models the common operational picture (COP) with dynamic

spatial information (or spatio-temporal/4D data) showing the situation in the affected area and the

locations of the resources.

The last section describes references to the DOLCE-Lite upper ontology and two domain ontologies:

GeoSPARQL for spatial concepts and W3C Time for temporal concepts. The EPISECC Ontology model

described in this chapter is the first version of the ontology model since it will be further validated in

WP6 and elaborated in the Deliverable D4.5.

3.1. Ontology scope – the EPISECC use case

The first step in ontology development is definition of its domain and scope.

The EPISECC project has a distinctive universe of discourse defined as ‘a response to a critical event’

which is analysed and described in Deliverable 4.2 “Taxonomy model”. Focus is on the disasters’

relief period, namely first 72 hours after the disaster’s sudden impact or early warning system alert,

and it concerns many concepts like processes, data, organizations, disasters, resources. The EPISECC

project keeps focus on the response to a disaster and that represents a domain of the EPISECC

Ontology model.

To define a scope of ontology, one should define its purpose and tasks the ontology should serve.

Questions the ontology should answer and the users should be defined also. The EPISECC Ontology

model is an application ontology serving emergency response tasks for the EPISECC use case. Thus,

the scope of the EPISECC Ontology model is defined by the following:

tasks defined by the CIS design, and

the EPISECC use case actors and information needed.

According to the EPISECC project proposal, the CIS should include appropriate semantic definitions

by taxonomies and/or ontologies. The proposal has recognised several challenges for informational

interoperability. The following three are the most important for the semantic structures in the CIS:

utilisation of existing and emerging standards,

utilisation of the EPISECC Taxonomy, and

dynamic information sharing.

The above stated challenge of dynamic information sharing is recognized as an important challenge

for informational interoperability as explained in the EPISECC project proposal: “Within this project,

the common information space is not regarded as something static, but more as a dynamic space,

where additional participants can be added spontaneously as required by the mission.”



www.episecc.eu

The EPISECC project elaborates three semantic structures facilitating semantic interoperability in CIS:

taxonomy, semantic repository and ontology model. The backbone semantic structure is the EPISECC

Taxonomy describing concepts used in ‘a response to a critical event’ and organizing them in

hierarchies and facets (D4.2). The EPISECC Data model provides database structure called Semantic

Repository for the storage of the semantic descriptions: the EPISECC Taxonomy, concepts used in

standards such as CAP and EMSI, and emergency organisations concepts. The EPISECC Semantic

Repository supports the semantic mapping services in CIS (D4.3). The third semantic structure of the

EPISECC project is the EPISECC Ontology model and its main objective is to enhance dynamic

information sharing. The EPISECC Ontology model describes the EPISECC use case as a model of

domain knowledge with references to the upper ontologies what enables dynamic merging of data.

Semantically corresponding concepts are identified and associated and the heterogeneous data can

be integrated. Thus, the task of the EPISECC Ontology model within the CIS design is to ease adding

of additional participants, dynamically and as required by the mission.

The EPISECC use case narrows down the domain of emergency response to a scenario designed for

the Proof of Concept. Deliverable 6.1 “Proof of Concept design” elaborates the scenario and a brief

description of the scenario follows.

The scenario describes the earthquake in Northern Italy followed by a dam break in Austria and

flooding and it covers the real field exercise which will be held in Friuli region in Italy in September

2016. The exercise will be monitored and analysed by the EPISECC consortium as described in D6.1.

The scenario and the field exercise involve the following:

cross-border situation between Italy, Slovenia, Austria and Croatia;

various organisations such as Local Emergency Management Authorities (LEMA), 112 centres,

national civil protection services, humanitarian organisations and first responders;

various tasks such as command and coordination on tactical level, assessment of the

situation, planning and conducting the response (search and rescue, medical service,

evacuation, protection and managing supply).

The scenario is divided in two episodes and use cases as follows.

• Episode 1: Main earthquake and aftershock causing partial collapse of roads and railways

Use-cases:

o Local Emergency Management Authority (LEMA) collects early warnings and

situation assessment info and compiles situation awareness

o Italian government requests help from Austria and Slovenia

o Italian government requests help from the Emergency Response Communications

Centre

• Episode 2: Dam break and flooding

Use-cases:

o Austria informs Slovenia and Italy

o Austria, Slovenia and Italy prepare for the dam break



www.episecc.eu

The episodes and use cases are described in D6.1 “Proof of Concept design” including descriptions of

the course of events, tools used, information needed and exchanged. The analysis of the use cases

shows that the information that needs to be exchanged compiles the common operational picture.

Thus, the interoperability needs will focus on exchanging data that composes the common

operational picture.

Common operational picture is defined in [23] as follows: “A common operating (operational) picture

is established and maintained by the gathering, collating, synthesizing, and disseminating of incident

information to all appropriate parties involved in an incident. Achieving a common operating picture

allows on−scene and off−scene personnel to have the same information about the incident, including

the availability and location of resources, personnel, and the status of requests for assistance.

Additionally, a common operating picture offers an overview of an incident thereby providing incident

information which enables the Incident Commander (IC), Unified Command (UC), and supporting

agencies and organizations to make effective, consistent, and timely decisions. In order to maintain

situational awareness, communications and incident information must be updated continually.”

Zlatanova et al. [24] model the data of the common operational picture as shown on Figure 4.

Figure 4: The common operational picture data classes (adopted from [24])

Data composing the common operation picture can be classified to static and dynamic data. Static

data exists prior the disaster occurred and it includes topographic maps, critical infrastructure data,

vulnerable objects data, population data, risk maps etc. Dynamic data consists of operational and

situational data and is collected during the emergency response. Operational data describes the

emergency response operations such as locations of rescue teams and other resources that can be

commanded. Situational data describes the situation in affected area such as disaster location,

effected people and properties, meteorological data etc.

The EPISECC use case focuses on the dynamic data and the static data is omitted from further

analysis. Table 1 summarises the exchanged and dynamic data from the scenario’s episodes and use

cases. Where applicable, data description uses the concepts and terms from the EPISECC Taxonomy.



www.episecc.eu

Table 1: The EPISECC use case data

No. Data class Data description

1 Operational data

Emergency response process (operation)

type of process (rescue, evacuation, etc.)

status of process (planned, in progress, etc.)

priority of process (high, medium, low)

capability of process (yes, no, partially)

responsible organization

2 Operational data

Resource needed/deployed

type of resource (human, material, machinery, vehicle, etc.)

capability of resource (yes, no, partially)

status of resource (available, needed, in use, etc.)

quantity of resource

3 Situational data

Disaster type of disaster (earthquake, flood, etc.)

progress of disaster (in progress, stopped, etc.)

cause of disaster (nature, humans, technology)

earthquake epicentre

earthquake magnitude

water reservoir water level

water reservoir risk level

4 Situational data

Affected area size of affected area

number of affected inhabitants

type of affected critical infrastructure

status of affected critical infrastructure

type of affected vulnerable objects

status of affected vulnerable objects

5 Situational data

Damages type of damaged objects

estimation of damages (number of objects, financial value, etc.)

6 Situational data

Casualties type of casualties

status of casualties

number of casualties

7 Situational data

Weather (actual and forecast)

temperature

humidity/rain

wind speed

wind direction

pressure

All the EPISECC use case data is spatio-temporal data or 4D data which means that includes

geolocation and reference to time. Geolocation could be represented with a point, line, polygon or a

collection of the points, lines and polygons. Different systems for the geolocating could be used such



www.episecc.eu

as the coordinates in one of the reference coordinate systems (e.g. WGS 84), place names,

addresses, the grid/sector codes defined by the emergency and risk plans, etc. Time reference could

include the time interval or the instant in time and be described by year, month, week, day, hour,

minute and second.

Some examples of the spatio-temporal data in the common operational picture follows. The

emergency response process could be geolocated by the point or polygon showing the operation’s

scene. As the process evolve in time, its scene changes and the polygon representing operation’s

scene changes its geometry in time. The location of the rescue team could be represented by the

moving point, a flood by spreading polygon etc.

Figure 5 shows the EPISECC Ontology model as spatio-temporal ontology that models data for the

EPISECC use case. This model should answer on question: Who, where and when is conducting what

operations?

Figure 5: The EPISECC Ontology model’s scope

To conclude, the scope of the EPISECC Ontology model encompasses the situational and operational

data exchanged among the organisations in the EPISECC use case. The EPISECC Ontology models the

common operational picture with dynamic spatial information (or spatio-temporal/4D data) showing

the situation in affected area and the locations of the resources.

3.2. Ontology conceptual model

The ontology development starts from reusing already developed ontologies and a brief description

of existing and relevant ontologies is given in the next section. Forthcoming sections explain scope

and key concepts of the ontology, and the last section gives references to the upper and domain

ontologies.



www.episecc.eu

3.2.1. An overview of the existing ontologies

There are libraries of reusable ontologies (or design patterns) such as Ontology design pattern Web

portal [18], but there is still no reference ontology specifically intended for the emergency or disaster

management. One of the reasons could be that the domain is quite complex and it could be seen as a

composition of several human domains such as disasters, organisations, people, events, workflows,

resources, infrastructures, policy, etc.

The importance of having a common understanding in the emergency management has been

recognised and different vocabularies have been created, but further development towards

reference ontology model has just started. An overview of efforts is given in [25] and it shows that

several attempts are made but they are limited either to one disaster type, to one infrastructure

system, to the method of development etc. Another overview of existing ontologies for disaster

management is elaborated by the FP7 project DRIVER and is given in [7]. The authors identified a

total of 11 subject areas represented in contemporary crisis information systems including critical

infrastructures (20%), resource management (13%), decision support (13.3%), situation awareness

(13.3%), response coordination (13.3%), command and control (6.7%) and other types (26.7%) such

as humanitarian response and relief. But, there is still no one model attempting to cover the

emergency and disaster management.

The FP7 project DISASTER developed the EMERGEL ontology [26] based on the Simple Knowledge

Organisation System (SKOS) model. The EMERGEL interprets a disaster as a kind of event. Three

ontology’s parts are developed as follows:

core module, referenced to the classes from the upper-level ontology DOLCE+DnS Ultralite;

transversal modules, used for space-time representation; and

vertical modules, used for representation of standard classifications of map symbol sets,

chemical substances, transport codes, etc.

The World Wide Web Consortium (W3C) published the report “Emergency Information

Interoperability Frameworks” in 2009 [8]. The undertaken work included several approaches: from

building the conceptual mind map, through using Wordle for generating the most used terms on the

Web, to studying the existing standards, information systems and research projects such as Tactical

Situational Object (TSO), OCHA, Sahana and the FP6 project ORCHESTRA. Still, the report describes

only candidate components for the emergency management ontology based on the common use

cases.

For the EPISECC Ontology model development, the above mentioned work is analysed and none of

the proposed ontologies could be reused. There are reference ontologies to be used as domain and

upper-level ontologies. Looking at the emergency management sub-domains, two domain ontologies

are selected for the development of the EPISECC Ontology model:

GeoSPARQL as domain ontology for spatial data [15], and

W3C Time as domain ontology for temporal data [16].

As a reference upper level ontology, the DOLCE-Lite ontology is selected [14].



www.episecc.eu

3.2.2. Ontology model’s elements

Ontology model is a conceptual model of a domain and it could be decomposed in three main

elements as follows [27]:

classes,

properties, and

individuals.

Classes describe concepts in the domain and they classify individuals or other classes. Individuals are

instantiations of the classes and are represented by data items. Properties describe relations and are

expressed as verbs, e.g. the verb ‘uses’ describes relation between an organisation and a resource.

Properties could be established between the following:

classes, e.g. ‘Vehicle’ is subclass of ‘Resource’;

individuals and classes, e.g. ’Water tank id 345’ is of type ‘Vehicle’;

individuals, e.g. ‘Water tank id 345’ belongs to ‘Fire brigade of the City of Split’.

Further more, OWL language in ontology schemas use two types of properties:

object properties for relating individuals to individuals, and

data type properties for relating individuals to data values.

Class could have subclasses and property could have subproperties, thus constituting the hierarchies

of the classes and properties. Although both the object-oriented and the ontology models use

classes, properties and inheritance, there are significant differences in these two paradigms. Some of

the ontology model’s characteristics that differ from object-oriented are the following:

properties exist independently of classes and can form a hierarchy,

an individual can belong to more then one class,

classes can be defined by set-theoretic constructs, and

inheritance propagates only on class membership up to the class hierarchy tree.

Figure 6 shows three main elements of the ontology model and the relations between them.

Figure 6: Ontology model’s main elements and their relations (adopted from [27])



www.episecc.eu

Individual is an instance of a class. Class has a property. Individual is a subject and an object of a

property. Property can have a class for its domain and range e.g. the class ‘Vehicle’ can have the

property ‘belongs to’. The property ‘belongs to’ can have a range: the class ‘Organisation’; and a

domain : the class ‘Resources’. ’Water tank id 345’ is an instance of the class ‘Vehicle’ and is subject

of the property ‘belongs to’.

Properties could have attributes such as cardinality, value type, inverse, etc. Classes could be defined

by property restriction. Property restriction describes the class by restricting the values allowed for

certain properties or putting the constraints on individuals for being a member of the class e.g. class

‘Blocked emergency ingress’ are emergency routes with at least one blocked road along the route.

Besides classes and properties, a conceptual ontology model can define axioms and rules for data

interpretation and reasoning. Axioms describe additional rules which exist between concepts and

properties. Based on the ontology model elements and by use of inferencing, the reasoning

algorithms can discover new relationships which are not explicitly stated in the model, and thus

extend semantic description of the domain. Reasoning algorithms use rules of logic to infer new

statements from available knowledge stored in the ontology.

Ontology conceptual model is expressed as one or more directed graphs. Figure 7a shows the

elements of directed graph as follows:

subject representing class or individual,

predicate representing property, and

object representing class or individual.

Figure 7: Example of the directed graph: generic (a) and specific one (b)

Figure 7b shows an example of the directed graph representing that the individual ’Water tank id

345’ belongs to the individual ‘Fire brigade of the City of Split’. Additional descriptions such as

domains and ranges are documented by a text coupled with the directed graphs.



www.episecc.eu

3.2.3. Key concepts and their relations

Knowing what is the scope of ontology, a list of key concepts can be defined. For the EPISECC

Ontology model, a subset of concepts of the EPISECC Taxonomy (D4.2) is selected according to the

scope of the EPISECC use case. The ontology model does not completely follow the EPISECC

Taxonomy classification because the ontology model is not a classification system but it should

describe the reality by modelling classes and relationships between them. E.g. for the EPISECC Use

case, the concept ‘Process’ is not a subclass of the EPISECC Taxonomy concept ‘Resource’ but the

main class of the ontology model. Besides the concepts and their hierarchy, the relationships or

properties between classes are derived. Figure 8 shows the main concepts modelled as ontology

classes (shown as ovals) and properties (shown as links with arrows).

PROCESS

DISASTER

ORGANISATION

RESOURCE

COMMON OPERATIONAL

PICTURE

invokes

executed by

uses

uses

has available

Figure 8: Directed graph of the main classes and properties

Five main classes are as follows:

Disaster

Any situation which has or may have a severe impact on people, the environment, or

property, including cultural heritage (D4.2).

Process

Process is a set of actions aiming for a certain result, executed by an organisation during a

response to a critical event (D4.2).

Resource

Assets an organisation has available for the response to a critical event (D4.2).

Organisation

An organisation is a unit established to meet goals related to disaster management. It is

structured along its management, which defines the relationships between responsibilities,

tasks and its structure (D4.2).

Common operational picture

A single identical display of relevant information shared by more than one command [28].



www.episecc.eu

The main classes are related by the properties: ‘invokes’, ‘uses’, ‘executed by’ and ‘has available’.

Class ‘Disaster’ is further elaborated as shown on Figure 9. Subclasses of ‘Disaster’ follow the EPISECC

Taxonomy classification of the facet ‘Disaster type’ which has 18 subclasses on the first level of the

classification (e.g. ‘Avalanche’, ‘Earthquake’, etc.) and 26 subclasses on the second level of the

classification (e.g. ‘Flash flood’, ‘Urban flood’, etc.). Their definitions are given in the Annex of the

Deliverable 4.2 “Taxonomy model”.

AVALANCHE

DISASTER DISASTER CAUSE

FLASH FLOOD

EARTHQUAKE FLOOD TSUNAMI

URBAN FLOOD

... ...

...

DISASTER PROGRESS

EPICENTRE

MAGNITUDE

has e

picen

tre

has

mag

nitu

de

has cause

has pro

gress

WATER RESERVOIR RISK LEVEL

WATER LEVEL

has risk level

has wa

ter lev

el

DISASTER OBJECT has affected

object

PROPERTYPEOPLE ...

...

subclass of ... classes not shown due to the limited space

Figure 9: Directed graph of the class Disaster

Due to the limited paper space, only few ‘Disaster’ subclasses are shown on Figure 9. Class ‘Disaster

object’ follows the EPISECC Taxonomy classification while the classes ‘Disaster progress’ and ‘Disaster

cause’ are not further classified and they could contain individuals (or data items) such as

‘technological cause’ or ‘disaster in progress’, respectively. Additional classes are introduced to the

ontology model beside the ones from the EPISECC Taxonomy. ‘Water reservoir’ is introduced as a



www.episecc.eu

type of property affected by a disaster and thus it represents a subclass of the EPISECC Taxonomy

class ‘Property’. ‘Water level’, ‘Risk level’, ‘Magnitude’ and ‘Epicentre’ are classes containing

individuals (or data items) coming from early warning systems and Earth observations systems and

could be considered as subclasses of the EPISECC Taxonomy class ‘Data’.

Concepts describing observations and measurements are complex concepts and they could be

further elaborated by use of domain ontologies such as Semantic Web for Earth and Environmental

Terminology (SWEET) [29] or Semantic Sensor Network (SSN) [30].

Figure 9 shows all properties between the classes with the verb explaining their meanings (shown as

links with arrows). Link ending with arrow without fill colour represents ‘is-a’ or ‘subclass of’

property.

Class ‘Process’ is elaborated on the Figure 10. Subclasses of ‘Process’ follow the EPISECC Taxonomy

classification of the facet ‘Process type’ which has 5 subclasses on the first level of the classification

(e.g. ‘Command & control’, ‘Physical response’, etc.), 22 subclasses on the second level of the

classification (e.g. ‘Decontamination’, ‘Search for people’, etc.), and 2 subclasses on the third level of

the classification. Their definitions are given in the Annex of the Deliverable 4.2 “Taxonomy model”.

Due to the limited paper space, only few ‘Process’ subclasses are shown on the Figure 8. The classes

‘Process status’, ‘Priority’ and ‘Capability’ are not further classified and they could contain individuals

(or data items) such as ‘planned’ or ‘high priority’ or ‘partially capable’, respectively.

Figure 10. shows all properties between the classes with the verb explaining their meanings.

COMMAND & CONTROL

PROCESS CAPABILITY

DECONTA-MINATION

INTERACTION WITH PEOPLE

PHYSICAL RESPONSE

RESOURCES MANAGEMENT

SEARCH FOR PEOPLE

... ...

...

PRIORITY

has capability

has pri

ority

PROCESS STATUS

has s

tatu

s

ORGANISATION executed by

subclass of

... classes not shown due to the limited space

Figure 10: Directed graph of the class Process



www.episecc.eu

Class ‘Resource’ is elaborated on the Figure 11. Subclasses of ‘Resource’ follow the EPISECC

Taxonomy classification of the facet ‘Resource type’ which has 5 subclasses on the first level of the

classification (e.g. ‘Animal’, ‘Physical’, etc.), 11 subclasses on the second level of the classification

(e.g. ‘Decontamination’, ‘Search for people’, etc.), 31 subclasses on the third level and additional

classes on the fourth and fifth levels of the classification.

Subclass ‘Process’ is omitted from the classification of the ‘Resource’ class because the ‘Process’ is

modelled as the main class in the EPISECC Ontology model.

The classes ‘Resource status’ and ‘Capability’ are not further classified and they could contain

individuals (or data items) such as ‘in use’ or ‘partially capable’, respectively.

Class ‘Quantity’ is also not further classified and it could contain data items such as numbers

representing quantities. The concept of quantity is a complex concept including measuring units etc

and it could be further elaborated by use of domain ontologies such as Quantities, Units, Dimensions

and Data Types Ontologies (QUDT) [31].


ANIMAL

RESOURCE CAPABILITY

CIVIL PROTECTION MEMBER

POLICEMAN...

QUANTITY

has capability

has qu

antity

RESOURCE STATUS

has s

tatu

s

PROCESS uses

subclass of

... classes not shown due to the limited space

FINANCIAL HUMAN PHYSICALINSTITUTIONAL

Figure 11: Directed graph of the class Resource



www.episecc.eu

Class ‘Organisation’ is elaborated on the Figure 12. Subclasses of ‘Organisation’ follow two EPISECC

Taxonomy facets classifications. Facet ‘Organisation type’ has 3 subclasses: ‘Governmental’, ‘Non-

governmental’ and ‘Private’. Facet ‘Specialisation’ has 5 subclasses (e.g. ‘Civil protection’, ‘Emergency

medical assistance’, etc.). The classes ‘Operational scope’ and ‘Spatial scope’ are not further

classified and they could contain individuals (or data items) such as ‘tactical’ or ‘international’,

respectively.


CIVIL PROTECTION

ORGANISATION SPATIAL SCOPE

OPERATIONAL SCOPE

has spatial scope

has op

eratio

nal sco

pe

PROCESS executed by

EMERGENCY MEDICAL

ASSISTANCE

HUMANITARIAN ASSISTANCE

SEARCH AND RESCUE

OPERATIONS

RECOVERY OF CULTURAL HERITAGE

GOVERNMENTALNON-

GOVERNMENTALPRIVATE

subclass of ... classes not showndue to the limited space

Figure 12: Directed graph of the class Organisation

Class ‘Common operational picture’ is elaborated on the Figure 13. ‘Common operational picture’

consists of ‘Static data’ and ‘Dynamic data’ according to the data model explained in Section 3.1.

‘Static data’ exists prior the disaster occurred such as topographic maps, population data, evacuation

routes, etc. and it is omitted from further analysis.

‘Dynamic data’ has two subclasses: ‘Situational data’ and ‘Operational data’.

‘Situational data’ describes situation in the affected area including disaster location, affected people

and properties, meteorological data, etc. and is further classified according to the ‘Data set content’

facet of the EPISECC Taxonomy. ‘Data set content’ facet contains 17 subclasses on the first level of

the classification and 7 subclasses on the second and third level (e.g. ‘Casualties’, Weather forecast’

etc.).

‘Operational data’ describes the emergency response operations such as the locations of rescue

teams and other resources that can be commanded.

Figure 13 shows the main classes ‘Process’ and ‘Resource’ as subclasses of the ‘Operational data’

which means that data describing processes and resources are considered as operational data. The



www.episecc.eu

main class ‘Disaster’ is subclass of ‘Situational data’ what means that data describing a disaster is

considered as situational data.

Figure 13 shows all properties between the classes with the verb explaining their meanings.

COMMON OPERATIONAL

PICTURE

STATIC DATA DYNAMIC DATA

uses

SITUATIONAL DATA

OPERATIONAL DATA

PROCESSRESOURCEAFFECTED

PEOPLE DATADAMAGE DATA

WEATHER FORECAST

...

containscont

ains

subclass of

... classes not showndue to the limited space

DISASTER

CASUALTIES HOMELESS MISSING TOTAL AFFECTED

Figure 13: Directed graph of the class Common operational picture

Additional to the classes and object properties shown on Figure 13, the following data type

properties of situational and operational data are used for detailed description of the situation:

‘has size’ (e.g. for ‘Affected area’),

‘has number’ (e.g. for ‘Casualties’), and

‘has value’ (e.g. for ‘Damages data’).

Weather is described by two classes: ‘Weather data’ and ‘Weather forecast’. As weather is a complex

concept, these two classes could be further elaborated by use of domain ontologies such as Semantic

Web for Earth and Environmental Terminology (SWEET) [29] or Semantic Sensor Network (SSN) [30].

The above sections use directed graphs to present the conceptual model of the EPISECC Ontology

model with its classes, subclasses and properties. The presented model completely covers the

EPISECC use case data listed in Table 1. The next section gives the EPISECC Ontology model

references to the selected domain and upper ontologies.



www.episecc.eu

3.2.4. References to domain and upper ontologies

For the EPISECC Ontology model development, two domain ontologies are selected and referenced:

GeoSPARQL as domain ontology for spatial data [15], and

W3C Time as domain ontology for temporal data [16].

As a reference upper level ontology, the DOLCE-Lite ontology [14] is selected and referenced.

The following sections explain the extension of the EPISECC Ontology model towards spatio-temporal

data and its references to the domain and upper level ontologies.

3.2.4.1. References to domain ontologies

The focus of the EPISECC Ontology is given to the modelling of spatio-temporal or 4D data showing

situational and operational data e.g. locations of the most urgent resources requested by the first

responders. Spatio-temporal data includes geolocation and reference to time. Geolocation could be

represented with different geometry entities such as points or surfaces, and different geolocating

systems such as WGS 84, the national coordinate system or addresses. Time reference could include

the time interval or the instant in time described by any time unit such as a day or a day plus hours

and minutes e.g. the emergency response process could be geolocated by the point or polygon

showing the operation’s scene. As the process evolve in time, the polygon representing the scene

changes its shape and position in time. Another example is the location of the rescue team which

could be represented by the moving point, a flood could be represented by spreading polygon etc.

Representation of 4D or dynamic features asks for mechanisms allowing representation of the

properties varying in space and time. Although the reference ontologies exist for the spatial and

temporal data, putting these two concepts together requires solution for a new concept: evolution of

concepts in time and space.

Several approaches for the 4D data ontology modelling have been reported, which a briefly explained

in [32]. Welty and Fikes in [33] have demonstrated that 4D Fluent model is the most appropriate one

for ontology modelling of 4D data using the OWL language. The 4D Fluent model maintains that all

entities are perdurants. The DOLCE ontology defines perdurants as follows [14]: “Perdurants (also

called occurrents) are entities that ‘happen in time’, they extend in time by accumulating different

‘temporal parts’, so that, at any time ‘t’ at which they exist, only their temporal parts at ‘t’ are

present.” Thus, perdurants have temporal parts and can be thought as ‘space-time worms’ whose

temporal parts are slices of the worm.

To represent entities varying also in space, Baučić in [34] has extended 4D Fluent model with spatio-

temporal parts of ‘space-time worms’. The spatio-temporal part represents 4D entity in the certain

moment in time with its location and geometry. E.g. flood can have its spatio-temporal part

consisting of polygon showing flooded area and time record stating when the flood had that extent,

as well as stating other flood characteristic valid for the same instant of time. Figure 14 shows the

model for common operational picture proposed in [34]. Ovals coloured in grey represent main

classes of the common operational picture and white ovals are classes of the reference domain



www.episecc.eu

ontologies. For the representation of dynamic or 4D data, the class ’Spatio-temporal part’ is

introduced and related with the property ‘is spatio-temporal part of’ to the class ‘Dynamic data’.

Figure 14 shows property ‘has spatiotemporal part’ relating ‘Dynamic data’ and ’Spatio-temporal

part’ and it is the inverse property of the ‘is spatio-temporal part of’.

COMMON OPERATIONAL

PICTURE

containscon

tain

s

DYNAMIC DATASTATIC DATASPATIOTEMPORAL

PART

has spatio-temporal part

has geometry

SPATIAL OBJECT

GEOMETRYFEATURE

Spatial relations(contains,intersects, within, touches, etc.)

Temporal relations(precedes, during,

started by, overlaps, etc.)

is inside

TEMPORAL ENTITY

INTERVALINSTANThas beginning

has end

SERIALIZATIONhas serialization

WKT GMLPOINT CURVE SURFACEGEOMTRY

COLLECTION

has serialization

XSD

DATA

TIME

has instant

Geospatial ontology(OGC GeoSPARQL, 2012)

Time ontology(W3C, 2006)

subclass of

Figure 14: Directed graph of common operational picture containing 4D data [34]

The selected domain ontologies further explain the spatial and temporal concepts. Thus, ’Spatio-

temporal part’ is referenced as a sublass of the class ‘Feature’ of the GeoSPARQL ontology and also

of the class ‘Temporal entity’ of the W3C Time ontology. Class ‘Static data’ is referenced as a sublass

only to the class ‘Feature’ because it does not contain temporal properties. A short description of

GeoSPARQL ontology and W3C Time ontology follows.

GeoSPARQL is Open Geospatial Consortium (OGC) standard [15]. This standard defines a core

RDF/OWL vocabulary for geographic information based on the General Feature Model [35], Simple

Features [36], Feature Geometry [37] and SQL for Multi Media [38]. Also, it includes a set of SPARQL

Protocol and RDF Query Language (SPARQL) extension functions and a set of Rule Interchange

Format (RIF) rules. GeoSPARQL defines a core set of classes, properties and datatypes that can be

used to construct query patterns. Figure 15 shows three main classes as follows:



www.episecc.eu

Spatial Object

This class represents everything that can have a spatial representation. It is superclass of

feature and geometry.

Feature

This class represents the top-level feature type and it is superclass of all feature types.

Geometry

The class represents the top-level geometry type and it is superclass of all geometry types.

has geometry

SPATIAL OBJECT

GEOMETRYFEATURE


Figure 15: GeoSPARQL directed graph [15]

The main property is ‘has geometry’ which links a feature with a geometry that represents its spatial

extent. GeoSPARQL does not restrict the cardinality of the ‘has geometry’ property. It is thus possible

for a feature to have many associated geometries. This standard includes properties describing

spatial relations of several models such as Simple Features Relation Family, Egenhofer Relation

Family and RCC8 Relation Family (e.g. ‘equal’, ‘disjoint’, ‘intersects’, ‘crosses’, etc.).

Figure 14 shows ‘has serialization’ property that connects a geometry object with its text-based

serialization. GeoSPARQL includes two serialization types which strongly affects the geometry

conceptualization. The serializations are as follows.

Well-known Text (WKT)

WKT aligns the geometry types with Simple Features standard [36].

Geography Markup Language (GML)

GML aligns the geometry types with geometry types of ISO 19107 Spatial Schema [37] and

uses Geography Markup Language Encoding Standard [39].

Well-known Text serialization includes definition of the coordinate reference system for the

geometry. It is expressed by URI and the OGC maintains a set of coordinate reference system URIs

under the http://www.opengis.net/def/crs/ namespace e.g. http://www.opengis.net/def/crs/OGC/

1.3/CRS84 denotes WGS 84 longitude-latitude. Additional to the coordinate reference systems, first

responders could use other systems for geolocations such as place names, addresses, the grid/sector

codes defined by the emergency and risk plans, etc. Therefore, the EPISECC Ontology model is

extended with the classes representing various types of the geolocation systems.



www.episecc.eu

Figure 16 shows three types of geolocation systems: ‘Address’, ‘Location ISO 125’ and ‘Emergency

sector’. Property ‘has location’ relates the ‘Spatiotemporal part’ with its geolocation system. Each

geolocation system is then related to the ‘Feature’ class of GeoSPARQL as a subclass.

DYNAMIC DATA

SPATIOTEMPORAL PART

LOCATION ISO 19125

ADDRESSEMERGENCY

SECTOR

has l

ocat

ion

has location

has lo

cation

... ...



is inside

TEMPORAL ENTITY

INTERVALINSTANT

has beginning

has end

has instanthas geometry

SPATIAL OBJECT

GEOMTERYFEATURE


has spatio-temporal part

subclass of

... classes not showndue to the limited space

Figure 16: Subclasses of the class ‘Spatiotemporal part’ (adopted from [34])

W3C Time ontology is W3C standard [16]. This standard presents an ontology of temporal concepts

including temporal relations among instants and intervals, together with information about durations

and date-time information. Figure 17 shows three main classes as follows:

Temporal entity

This class represents everything that can have a temporal representation. It is superclass of

instant and interval.

Instant

This class represents a precise moment of time.

Interval

This class represents a period of time.



www.episecc.eu

The standard further explains that “Intervals are, intuitively, things with extent and instants are,

intuitively, point-like in that they have no interior points. It is generally safe to think of an instant as

an interval with zero length, where the beginning and end are the same.”



is inside

TEMPORAL ENTITY

INTERVALINSTANT

has beginning

has end

has instant

Figure 17: W3C Time directed graph [16]

Four main properties are as follows:

‘is inside’ describes relation between an instant and an interval where instant is placed inside

interval but it is not intended to include beginnings and ends of intervals;

‘has instant’ describes relation between an instant and a temporal entity where instant

represents a unique moment of time;

‘has beginning’ describes relation between an instant and a temporal entity where instant

represents a unique and beginning point of the entity;

‘has end’ ‘describes relation between instant and temporal entity where instant represents a

unique and end point of the entity.

Figure 14 shows ‘has serialization’ property that connects a instant with its text-based serialization.

W3C Time defines XSD Date Time serialization that is XML representation of date and time.

Temporal relations are based on a calculus of binary relations on intervals (e.g., meets, overlaps) for

representing qualitative temporal information [40]. W3C Time ontology provides the interval

relations such as ‘equals’, ‘before’, ‘meets’, ‘overlaps’, ‘starts’, during’, etc.

3.2.4.2. References to upper level ontology

As a reference upper level ontology, the DOLCE-Lite ontology is selected [14]. DOLCE is an acronym

for Descriptive Ontology for Linguistic and Cognitive Engineering and it is clear that DOLCE ontology

aims at capturing the ontological categories underlying natural language and human common sense.

Suffix ‘Lite’ stands for encoding version with most of predicates formalised in DOLCE.

Figure 18 shows DOLCE basic categories of a particular. The distinction between endurants (also

called continuants) and perdurants (also called occurrents) is related to their behaviour in time.

Endurants are wholly present at any time. Perdurants extend in time by accumulating different

temporal parts, so that, at any time they are only partially present, in the sense that some of their



www.episecc.eu

proper temporal parts (e.g., their previous or future phases) may be not present [14]. Qualities are

the basic entities we can perceive or measure: shapes, colours, sizes, sounds, weights, lengths, etc.

Abstract entities do not have spatial nor temporal qualities, and they are not qualities themselves.

Figure 18: DOLCE basic categories of particulars [14]

Figure 19 shows the main classes of the EPISECC Ontology model extended with 4D data

representation and referenced to the DOLCE-Lite ontology. Grey ovals represent DOLCE-Lite classes

and white ovals represent the EPISECC Ontology classes. The model corresponds to the one

described in [34] and is accommodated to the main classes of the EPISECC Ontology model. Due to

the limited paper space only main classes are shown on Figure 19.

References to domain and upper level ontologies enable the EPISECC Ontology model to be merged

with other semantic structures using the same reference ontologies. The semantic is expressed

formally and can be used to negotiate meaning, either for enabling cooperation between multiple

artificial agents or between artificial agents and humans.

There are other domain ontologies which could be referenced such as Semantic Web for Earth and

Environmental Terminology (SWEET) [29], Semantic Sensor Network (SSN) [30] and Quantities, Units,

Dimensions and Data Types Ontologies (QUDT) [31]. These ontologies include large number of

concepts for Earth observations, measurements, units etc. Because the focus of the EPISECC

Ontology model was on 4D data, they are omitted from the further study.



www.episecc.eu

PROCESS

DISASTER

ORGANISATION

RESOURCE

COMMON OPERATIONAL

PICTURE

invo

kes

executedBy

uses

use

s

containscont

ains

DYNAMICDATA

STATICDATA

SPATIOTEMPORAL PART

is spatio-temporal part of

hasGeometry

SPATIALOBJECT

GEOMETRYFEATURE

Spatial relations

(contains,

intersects, within,

touches, etc.)

Geospatial ontology(OGC GeoSPARQL, 2012)

Temporal relations

(precedes,

during, started by,

overlaps, etc.)

Time ontology(W3C, 2006)

isInside

TEMPORALENTITY

INTERVALINSTANT

hasB

eginn

ing

hasE

nd

STATE

PROCESS

AGENTIVE PHYSICAL OBJECT

NON – AGENTIVE PHYSICAL OBJECT

INFORMATION OBJECT

SPATIAL – LOCATION_q

TEMPORAL – LOCATION_q

PERDURANT

ENDURANT

ENDURANT

HUMAN

PHYSICAL

NON – AGENTIVE SOCIAL OBJECT

QUALITY

subclassOf

has

av

aila

ble

Figure 19: Directed graph of main EPISECC classes and with references to DOLCE-Lite, GeoSPARQL and W3C Time

ontology classes (adopted from [34])



www.episecc.eu

4. Ontology schema

This chapter describes the first implementation and validation of the EPISECC Ontology model. Once

the conceptual model is developed and upper and domain ontologies referenced, the ontology

schema can be created. Ontology schema is a formalisation of the conceptual model. Software-

interpretable constructs are defined by formal languages RDFS [19] and OWL [20]. The EPISECC

Ontology schema is created with Protégé Desktop software already used for the EPISECC Taxonomy

and the EPISECC Semantic repository. Protégé Desktop description is given in the Deliverable 4.2.

Advanced functions and plug-ins are used for the input of EPISECC Ontology model classes and

properties, search and reasoning. The EPISECC Ontology schema is stored in an OWL file locally on

the computer in RDF/XML syntax and an excerpt is given in the Annex. The first validation includes

testing of logical consistency by applying reasoning algorithms.

The second implementation and validation will be done through the Proof of Concept and validation

and described in the Deliverable 6.3. The final ontology schema will be elaborated in Task 4.5.

“Lessons learned from proof of concept and validation” and delivered in the Deliverable 4.5.

4.1. Implementation in Protégé Desktop

The EPISECC Ontology model classes and properties are inserted to the OWL model. The following

figures illustrates the Protégé Desktop interfaces.

Figure 20 shows imported domain ontologies GeoSPARQL and W3C Time. Their RDF files are

downloaded from the web and imported into the OWL file of the EPISECC Ontology schema. These

ontologies already contain other ontologies and their prefixes so they are indirectly imported too (e.g

GML and Simple Feature ontology).

Figure 20: Protégé Desktop interface showing imported ontologies



www.episecc.eu

Figure 21 shows two class hierarchies. Left hierarchy shows the first level of classes of the EPISECC

Ontology schema. Classes written in bold letters are defined by the EPISECC Ontology conceptual

model and classes written in regular letters are defined by GeoSPARQL and W3C Time ontologies e.g.

class ‘Spatiotemporal part’ is the EPISECC Ontology conceptual model class, ‘Spatial object’ is the

GeoSPARQL class and ‘Temporal entity’ is the W3C Time class. Right side of the Figure 21 shows the

class ‘Common

d4.4. ontology model for the episecc use case 4_deliverable_report.pdfepisecc_wp4_d4...

Documents