D4.5. - Taxonomy: Lessons learned 5_Deliverable... · standard (SKOS-thes) have been compared to...

www.episecc.eu

D4.5. - Taxonomy: Lessons learned

Grant agreement number: 607078 Date of deliverable: 2017-08-31

Date of project start: 2014-06-01 Date of submission: 2017-09-04

Duration of project: 2017-10-31 Deliverable approved by: HWC

Lead Beneficiary: UNIST

Contributing Beneficiaries: AIT

Establish Pan-European Information Space to Enhance seCurity of Citizens

http://www.episecc.eu/

www.episecc.eu

Executive Summary

The deliverable provides findings obtained after the validation process and the outcome of the

communication with project’s Advisory Board members as well as subsequent improvements of the

semantic structures: Taxonomy, Semantic repository and Ontology model. The Taxonomy has been

improved continuously each time input from Advisory Board members and external disaster

management experts has been obtained and finally after the discussion at the evaluation panel

within the validation process in Task 6.3. The Semantic Repository structure and implementing

standard (SKOS-thes) have been compared to the demands expressed during the validation process.

Particularly, the Ontology model for the EPISECC use case was refined according to the validation use

cases.

The deliverable goes through the project’s events and activities, which contribute to the validation

process and presents the implementation of the semantic structures throughout the process. The

additional sources of information for Taxonomy’s concepts and terms come from the technical and

humanitarian organisations and were provided by their representatives. The newly obtained

concepts were analysed regarding their use and relevance for the disaster response phase, mapped,

and accepted concepts were included in the Taxonomy.

Semantic Repository was prototyped and has passed several technical testing. During the validation

process, Semantic Repository was loaded with end users’ semantics and CIS’s components were

creating semantic annotations. The implemented SKOS-thes data model satisfied both requirements

related to storing end users’ semantics and supported CIS’s components. Analysis has shown that

several simplifications of the data model could be implemented, particularly in modelling of the

compound terms, and still satisfying the needs.

EPISECC scenario’s use cases were a basis for the validation of the Ontology model. The focus was on

spatio-temporal data constituting a common operational picture. The Ontology model was analysed

against competency questions, the questions an ontology model should be able to answer, and

improvements were proposed. As the Taxonomy is a constituting part of the Ontology model, the

improvements of the Taxonomy were propagated to the Ontology model. Both improvements are

incorporated in the final Ontology model.

Based on the findings, the deliverable shows the final assessment of the semantic structures in terms

of their perspective and significance for the disaster management, particularly the response phase.

The directions for further research are also investigated and presented at the end of the document.


2017-09-04 EPISECC_WP4_D4 5_Deliverable_Report.docx 168 |3

www.episecc.eu

Table of Content

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

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

List of Acronyms and Abbreviations ........................................................................................................ 6

1. Introduction ..................................................................................................................................... 7

2. Basis for additional research on semantics ..................................................................................... 9

2.1. Additional sources of concepts ................................................................................................ 9

2.2. Dry run at Advisory Board meeting ....................................................................................... 10

2.3. Proof of concept .................................................................................................................... 11

2.3.1. End users and concepts ................................................................................................. 12

2.3.2. EPISECC Semantic Repository prototype ....................................................................... 13

2.3.3. Semantic annotations .................................................................................................... 18

2.3.4. Evaluation panel ............................................................................................................ 23

3. Analysis and improvements .......................................................................................................... 26

3.1. EPISECC Taxonomy ................................................................................................................. 27

3.2. Data base model .................................................................................................................... 29

3.3. EPISECC Ontology model ....................................................................................................... 31

4. Conclusions .................................................................................................................................... 36

4.1. Significance and perspectives of the models ......................................................................... 36

4.2. Follow-up research ................................................................................................................ 37

Bibliography ........................................................................................................................................... 40

Annex ..................................................................................................................................................... 41

I. The selected set of concepts for the PoC ...................................................................................... 41

II. EPISECC Taxonomy ........................................................................................................................ 45

III. EPISECC Ontology model ............................................................................................................... 75



www.episecc.eu

List of Tables

Table 1: Distribution of the new concepts ............................................................................................ 10

Table 2: Organisations exchanging messages during PoC ..................................................................... 12

Table 3: Sub-structures’ elements of the SKOS-thes model used during PoC ...................................... 14

Table 4: Evaluators’ suggestions and reflections to them .................................................................... 24

Table 5: Ontology model’s elements and improvements ..................................................................... 33



www.episecc.eu

List of Figures

Figure 1: SKOS-thes directed graph ....................................................................................................... 13

Figure 2: The sub-structures of the EPISECC Semantic Repository prototype for the PoC ................... 13

Figure 3: SKOS-thes elements used for the EPISECC Semantic Repository prototype in PoC .............. 15

Figure 4: An excerpt from the EPISECC Semantic Repository prototype in PoC showing concepts ..... 15

Figure 5: MRAS’s concept ‘Iskanje in reševanje’ ................................................................................... 16

Figure 6: CNVVF’s concept ‘Autobottepompa’ ..................................................................................... 17

Figure 7: Compound term ‘(Specialised vehicle, on road)’ ................................................................... 17

Figure 8: The Semantic Repository architecture ................................................................................... 18

Figure 9: UML Use case diagram s of Semantic Service offered by CIS (deliverable 4.3) ..................... 19

Figure 10: An excerpt of end users’ semantic mappings against the EPISECC Taxonomy concepts .... 20

Figure 11: SPARQL query executing semantic matching over the EPISECC Semantic Repository ........ 21

Figure 12: SPARQL query result for semantic matching between CNVVF’s and MRAS’s concepts ...... 21

Figure 13: Result of the semantic matching request done by SPARQL over the EPISECC Semantic

Repository ............................................................................................................................................. 22



www.episecc.eu

List of Acronyms and Abbreviations

Acronym /

Abbreviation Description

AB Advisory Board

API Application Programming Interface

CAP Common Alerting Protocol (OASIS standard)

CEN/WS European Committee for Standardization - Comité Européen de Normalisation

/ Workshop

CIS Common Information Space

CNVVF Italian National Firefighters Corps - Corpo Nazionale dei Vigili del Fuoco

COP Common Operational Picture

DISP Disaster Information Sharing Platform developed by HITEC

HTTP Hyper-Text Transfer Protocol

IT_CNVVF Italian National Firefighters Corps - Corpo Nazionale dei Vigili del Fuoco

JIXEL Tool for emergency management and interoperability developed by IES

JVP-SPLIT Public Freighters Troops from Split, Croatia - Javna Vatrogasna Postrojba

LEMA Local Emergency Management Authority

LifeX COP COP tool developed by Frequentis

MRAS Mountain Rescue Association of Slovenia

OWL Ontology Web Language

PCRAFVG Protezione Civile Regione Autonoma Friuli Venezia Giulia

PoC Proof of Concept

RDFS Resource Description Framework Schema

REST Representational State Transfer

SKOS Simple Knowledge Organisation System

SKOS-thes SKOS extension for thesauri

SPARQL SPARQL Protocol and RDF Query Language

TER-CDM TERminologies in Crisis and Disaster Management



www.episecc.eu

1. Introduction

The functionality of the models taxonomy, data and ontology models that have been developed

underwent validation during the proof of concept (hereinafter also referred to as the PoC).

Moreover, the EPISECC Taxonomy’s concepts and structure have been also improved based on

interviews with end users and, together with the Semantic repository, based on the outcome of the

dry run.

The EPISECC Taxonomy structure is built on existing documents and structures used by first

responders and organisations involved in the disaster response phase. The Taxonomy is a part of the

EPISECC solution for the common information space, particularly it is the core of the semantic

interoperability service, and it also serves as a semantic basis for the EPISECC ontology described in

the deliverable 4.4. The Taxonomy and methodology for its development are described in the

deliverable 4.2. However, based on the additional inputs received from end users, the Taxonomy has

been constantly improved.

Bearing in mind that different emergency organisations have different perspectives and roles during

disasters (for ex. organisations with predominantly technical focus like firefighters or those with

humanitarian focus like the Red Cross), the communication and validation with different types of end

users provide comprehensive input for improvement and fine-tuning. To that end, even prior to the

proof of concept, the discussions with practitioners at different management levels were organised.

Firefighters and Red Cross were the natural choice, since they are the most common technical and

humanitarian responders during disasters, respectively.

The Taxonomy has been continuously updated and improved using direct contacts with Advisory

Board (hereinafter also referred to as the AB) members (Austrian Red Cross), as well as outside AB

(Croatian Fire Brigade in Split). Their representatives provided the most common concepts they use

during the response phase, which were analysed and mapped to the Taxonomy to find gaps or

identify unnecessary elements in its structure. Moreover, the functionality of the EPISECC Taxonomy

was presented to the AB members during the dry run at AB meeting and validated during the proof

of concept by relevant external evaluators and end users.

The selected set of concepts from end users who were involved in the messages exchange

demonstration were entered in the EPISECC Semantic Repository and mapped to the Taxonomy. The

concepts are related to the content of the messages planned within the PoC’s scenario. The mapping

process was not directly validated by the end users, because practitioners’ availability to join this

exercise guided by the EPISECC team before the PoC was limited due to their professional duties. The

mapping process could not have been performed by end users alone, as this service needs an

adequate interface which has not been developed within the scope of the project. Therefore, the

EPISECC team performed it, taking care to avoid bias circumstances as much as possible during the

process.

This report is structured in four chapters. Following this introduction, the second chapter deals with

analysis of the further research in context of continuous work with project’s AB members as well as

discussion with external evaluators. The chapter explains how the collaboration with AB members



www.episecc.eu

and external evaluators during the dry run and the main validation event, namely PoC, has been

organised and the results were used for the further development of the semantic structures in the

Common Information Space (hereinafter also referred to as the CIS).

The third chapter outlays the analysis of the results from the dry run and PoC and their influence on

the semantic structures. Starting from the additional sources of information used for the Taxonomy

development after its first release, the analysis includes findings and feedbacks from AB members

and external evaluators. The results from the analysis are summarised and Taxonomy has been

improved accordingly. The detailed structure of the new version of the Taxonomy and descriptions of

the concepts and facets are given in the Annex II. The chapter also provides the validation of the data

model for the EPISECC Semantic Repository. The analysis is based on PoC outcomes and continues

with the identification of potential improvements. The analysis also includes accompanied semantic

services. The last subsection of the chapter analyses use cases from the PoC and improves the

EPISECC Ontology model. The detailed structure of the improved model is given in the Annex III.

The fourth chapter identifies the significance of the project’s semantic structures, namely,

Taxonomy, Semantic repository and Ontology, and delivers their potential perspectives, which can be

important for their further development and covering existing gaps. The report ends with

conclusions and follow-up suggestions how to continue with the research in order to bring the

semantic services closer to daily application.



www.episecc.eu

2. Basis for additional research on semantics

Once the initial semantic structures were developed, the work continued based on the further

contacts with end users. The contacts with end users were established during the dry run session and

proof of concept, as well as in separate communication. This chapter describes the sources of

concepts that have been used for further development and improvement of the Taxonomy.

The additional work on the Taxonomy was based on the search for new concepts primarily focused

on end users’ practice, since the first version is mainly based on the desk research of available

standards, vocabularies, dictionaries and similar documents or semantic structures.

As elaborated in the deliverable 4.2 the preliminary internal validation, which indicated some issues

to be considered in the further development, was the starting point for the improvements. Herein,

the external validation prior and during the proof of concept phase, is analysed.

The first implementation and testing of the data model for the EPISECC Semantic Repository was

done in parallel with the data model design as described in the deliverable 4.3. The second EPISECC

Data model implementation and technical testing was done in WP5 through the realisation of the

Semantic Repository in the open source Apache Jena database management system. Several

functional tests for technical verification were successfully performed prior to the PoC as described in

the deliverable 6.3. Finally, the EPISECC Data model validation was done during PoC as described in

WP6, deliverable 6.3. The EPISECC Semantic Repository prototype was created and loaded with data:

the EPISECC Taxonomy and selected sets of concepts from end users involved in the messages

exchange demonstration. Although the process of data entering into the EPISECC Semantic

Repository was not performed by the end users, the PoC showed that the proposed data model is

adequate for storing the EPISECC Taxonomy and end users’ concepts, as well as for execution of

semantic mapping and matching.

For the validation of the EPISECC Ontology schema a two stage approach is applied: first checking of

logical consistency and second the application of competency questions by using real world test data.

The first validation was done in parallel with the EPISECC Ontology schema development as

described in the deliverable 4.4. The second validation was done through the PoC. Based on the

PoC’s scenario and use cases, a list of competency questions was built. The Ontology model was

validated through its ability to answer the competency questions. The ontology development is an

iterative process. The first version of ontology is revised according to validation results. Also, changes

in the Taxonomy are propagated to the Ontology model because taxonomy is part of ontology.

2.1. Additional sources of concepts

In order to get as much information on concepts as possible disaster responders were directly

contacted and they provided examples of concepts usually applied during the disaster response

phase. The representatives of end users, usually one or two persons, were asked to provide twenty

to thirty concepts, which they found either most frequently used and/or very relevant for the

disaster response phase. The collected concepts were analysed and mapped to the Taxonomy. If a



www.episecc.eu

particular concept could not be mapped, further analysis was performed to see whether this

indicates a need to enlarge or restructure the EPISECC Taxonomy.

Even though there were difficulties to involve end users due to their daily obligations, 234 relevant

additional concepts were collected. Apart from the desk research based on available standards,

vocabularies, dictionaries and similar documents or semantic structures, the emphasis was to get

concepts usually used by end users in practice. Prior to the PoC, the Croatian firefighter troops centre

in Split was contacted and they provided concepts from their usual usage during disasters and

emergencies. Most of the concepts, mainly from operational and tactical levels, were provided from

repository of the Italian national fire corps. Furthermore, the project’s Advisory Board member from

Austrian Red Cross provided concepts form strategic and tactical perspective that may be used

during response to a disaster. For the purpose of PoC, concepts used by Slovenian mountain rescue

team, mainly at operational level, were obtained, as well. The Table 1 shows the distribution of the

concepts regarding organisations involved and the decision making levels.

Table 1: Distribution of the new concepts

Source Decision level Number of concepts

Croatian firefighters troops from Split tactical 22

Austrian Red Cross strategic/tactical 20

Italian national fire corps tactical/operational 101

Slovenian mountain rescue team tactical/operational 91

2.2. Dry run at Advisory Board meeting

During the dry run at the Advisory Board meeting in Vienna, November 2016, the semantic

annotation approach was discussed with the AB members. The concepts obtained from Croatian

firefighter troops from Split and Italian national fire corps’ repository were used in messages. For this

exercise, the first prototype was developed and implemented in SKOS model.

The example of the semantic mapping and semantic annotations used during the dry run in the

message sent by Italian Fire Brigade to Croatian Fire Brigade is the following:

Sender’s (Italian Fire Brigade: IT_CNVVF) concepts:

spegnimento incendio - mapped to the EPISECC Taxonomy as exact to (Extinguishing fire)

Punto di interesse - mapped to the EPISECC Taxonomy as broad to (Point, Operation execution)

Autoscala - mapped to the EPISECC Taxonomy as broad to (Lifting)

Receiver’s (Croatian Fire Brigade: JVP-SPLIT) concepts:

Gašenje vatre – mapped to the EPISECC Taxonomy as exact to (Extinguishing fire)

Mjesto okupljanja - mapped to the EPISECC Taxonomy as exact to (Area, Operation execution)

Autoljestve – mapped to the EPISECC Taxonomy as broad to (Lifting)



www.episecc.eu

Sent message:

L’urgenza di spegnimento incendio. Porta l’autoscala nel punto d’interesse.

Annotated message:

L’urgenza di spegnimento incendio (Gašenje vatre, ExactMatch). Porta l’autoscala (Autoljestve,

BroadMatch) nel punto d’interesse (Mjesto okupljanja, BroadMatch).

Even though it was brief demonstration of how semantics, particularly the Taxonomy and semantic

annotations, may be used in the messages to help first responders to better understand each other,

the reactions were positive and they expressed the need for such tool during the disaster response

phase.

After the demonstration, structured interviews were conducted with five AB members coming from

different decision making levels. One part of the interview was dedicated to the information, namely

about the content of the collected and distributed information. Here are some highlights of the

information they mentioned:

current situation in terms of ‘what is going on’ and ‘who is doing what’;

who is communicating to the public/media and what are the information;

affected people: homeless, victims, injured, casualties, their conditions;

affected infrastructure (roads, dams, highways, bridges, railways, electricity, hospitals, etc.);

affected industries, agriculture, cultural heritage;

available resources;

location and missions;

location and availability of resources;

administrative issues;

international assistance.

The dry run provided good opportunity to discuss semantic annotation approach with AB members

and to check whether the Taxonomy’s concepts are in line with the content of the messages

exchanged during the response phase.

2.3. Proof of concept

The proof of concept (hereinafter also referred to as PoC) was the central event for the validation of

the EPISECC semantic structures. This chapter explains in detail the preparation and implementation

of the Semantic Repository prototype used in the PoC. Furthermore, the chapter describes the

process of collecting new concepts from end users involved in the PoC’s scenario as well as creation

of semantic annotations. At the end the outcomes and reflections from the evaluation panel are

given.



www.episecc.eu

2.3.1. End users and concepts

During the PoC three organisations (hereinafter also referred to as end users), which connected their

tools via CIS, exchanged their messages. Table 2 lists the organisations, their roles and the

information management tools used during the PoC. CNVVF and MRAS were using their concepts,

while PCRAFVG was using concepts based on EPISECC Taxonomy in English language.

Table 2: Organisations exchanging messages during PoC

Acronym Full name Role Information

management tool used

PCRAFVG

Protezione Civile Regione

Autonoma Friuli Venezia Giulia

(Civil Protection Authority)

local emergency

management authority

(LEMA)

LifeX COP

CNVVF

Corpo Nazionale dei Vigili del

Fuoco

(Italian National Fire Corps)

responder

organisation

Jixel

MRAS Mountain Rescue

Association of Slovenia

responder

organisation

Disp

The selection of the concepts was strictly based on the developed scenario and planned protocol for

exchange of messages, which are described in detail in the deliverable 6.2. Since the character of the

PoC’s scenario was predominantly operational, most of the concepts used in the PoC are mainly

related to the operational and only partially to the tactical level, used by technical organisations:

Italian National Fire Corps and Mountain Rescue Association of Slovenia. PCRAFVG (LEMA) adapted

and used corresponding concepts based on EPISECC Taxonomy in English language.

There were already a substantial number of concepts from the Italian National Fire Corps repository,

and Mountain Rescue Association of Slovenia provided concepts that are usually and frequently used

by them during the emergency and disaster response. Therefore, the selected set of concepts for the

PoC is adapted to the scenario as well as to the concepts provided from CNVVF and MRAS. Besides

those obtained initially from MRAS, other concepts, more suitable for POC’s scenario, were defined

in collaboration with Slovenian representatives. PCRAFVG defined own concepts that match at least

one concept from either CNVVF or MRAS. Having only extractions of the concepts from end users,

such procedure ensured that messages would have semantic annotations. The concepts prepared for

semantic matching in PoC are shown in Annex I.



www.episecc.eu

2.3.2. EPISECC Semantic Repository prototype

SKOS-thes is selected as data model for the EPISECC Semantic Repository. The whole model contains

12 classes, 36 object properties, 3 data properties, 24 annotation properties and 4 datatypes.

Deliverable 4.4, section 3.2.2 explains the SKOS-thes model and its elements in details. Figure 1

shows the SKOS-thes model as a directed graph.

Figure 1: SKOS-thes directed graph

The structure of the EPISECC Semantic Repository prototype, shown in the Figure 2, consists of four

sub-structures: the EPISECC Taxonomy, PCRAFVG’s concepts, CNVVF’s concepts and MRAS’s

concepts. Semantic relations ‘has exact match’ and ‘has broader match’ are used to represent

classification of the organisations’ concepts against the EPISECC Taxonomy’s concepts.

Figure 2: The sub-structures of the EPISECC Semantic Repository prototype for the PoC



www.episecc.eu

For the PoC, the complete SKOS-thes model was created, although not all the classes and properties

were used. Table 3 shows the sub-structures’ elements and corresponding SKOS-thes elements used

during the PoC.

Table 3: Sub-structures’ elements of the SKOS-thes model used during PoC

Sub- structure Sub structure’s element SKOS-thes elements

(classes and properties)

Sub-structure - Concept Scheme (class)

EPISECC Taxonomy

Concept

Concept (class)

Is in Scheme (property)

Has Preferred Label (property)

Facet

Thesaurus Array (class)

Subordinate Array/Super ordinate (property)

Member (property)

Definition Description (property)

Term Preferred Term (class)

Literal Form (property)

Concept hierarchy Narrower/Broader (property)

Organisation participating in PoC

Concept

Concept (class)

Is in Scheme (property)

Has Preferred Label (property)

Definition Description (property)

Term Preferred Term (class)

Literal Form (property)

Classification of organisations‘ concepts against the EPISECC Taxonomy

Concept A belongs to the class described by Concept B.

Has exact match (property)

Concept A has broad match in Concept B if A is more specific concept than the class described by Concept B.

Has broader match (property)

The prototype was loaded with the EPISECC Taxonomy and selected sets of concepts from end users

involved in the messages exchange demonstration. Considering corresponding SKOS-thes elements,

the data items were loaded as individuals of classes: Concept, Concept Scheme, Label, Preferred

Term and Thesaurus Array. The content of the EPISECC Semantic Repository prototype prepared for

PoC is as follows (Figure 3):

4 concept schemes,

358 concepts,



www.episecc.eu

215 labels,

388 preferred terms, and

30 thesaurus arrays.

Figure 3: SKOS-thes elements used for the EPISECC Semantic Repository prototype in PoC

Moreover, 248 end users’ concepts were mapped to the EPISECC Taxonomy’s concepts using two

SKOS-thes properties: ‘has exact match’ and ‘has broader match’ (Figure 4). The excerpt from the

EPISECC Semantic prototype, showing the list of concepts together with their corresponding

preferred terms, concept schemas and semantic relations to the EPISECC Taxonomy (‘has exact

match’, ‘has broader match’), is shown in the Figure 4.

Figure 4: An excerpt from the EPISECC Semantic Repository prototype in PoC showing concepts



www.episecc.eu

Figure 5 shows how MRAS’s concept ‘Iskanje in reševanje’ is entered as an individual data item

(hereinafter also referred to as individual) and as a member of SKOS-thes class Concept. The

concept’s property assertions are: ‘is in Scheme’ equals to MRAS; ‘preferred label’ equals to ‘Iskanje

in reševanje (term)’ and ‘has exact match’ equals to ‘Search and rescue’ meaning that ‘Iskanje in

reševanje’ is classified as concept ‘Search and rescue’ of the EPISECC Taxonomy.

Figure 5: MRAS’s concept ‘Iskanje in reševanje’

The prototype includes alternative labels in cases where more then one term is used for the same

concept. They are stored as members of class Label. Such example is shown in the Figure 6Fehler!

Verweisquelle konnte nicht gefunden werden.. CNVVF’s concept ‘Autobottepompa’ has preferred

label ‘Autobottepompa (term)’ with literal form “Autobottepompa”@it and alternative label

‘Autobottepompa (a1term)’ with literal term “ABP”@it. Also, the concept has its description and

properties: ‘is in Scheme’ equals to CNVVF and ‘has broader match’ equals to ‘(Specialised vehicle, on

road)’ meaning that ‘Autobottepompa’ is more specific concept than the concept defined by

compound term ‘(Specialised vehicle, on road)’ of the EPISECC Taxonomy.

The compound term was used when a real concept from an end user was classified using values of at

least two EPISECC Taxonomy’s facets. The SKOS-thes models compound terms by using two classes

‘Compound Equivalence’ and ‘Split Non Preferred Term’ and two properties ‘Plus Use Term’ and ‘Plus

Used For Term’. For the EPISECC Semantic Repository prototype in PoC, the simplified model was

used, and the adequate compound terms were defined and entered as new individuals of the class

Concept. Compound terms were treated as other concepts, which simplified their use in the process

of semantic matching described in the section 2.3.3. Compound terms have their labels, descriptions,

preffered labels and are in the concept scheme EPISECC. Preferred label of the compound term has

its literal form. An example for the compound term ‘(Specialised vehicle, on road)’ is given in the

Figure 7. The Figure 6 shows that concept ’Autobottepompa’ has the property ‘has broader match’ in

relation to the compound term ‘(Specialised vehicle, on road)’.



www.episecc.eu

Figure 6: CNVVF’s concept ‘Autobottepompa’

Figure 7: Compound term ‘(Specialised vehicle, on road)’

The EPISECC Semantic Repository prototype was created using Desktop Protégé. The proposed SKOS-

thes model was opened as RDF file containing the structure and then data items were entered. The

resulting OWL file was loaded in the Apache Jena framework, the selected database management

system for the implementation of the EPISECC Semantic Repository prototype and Semantic Services.

Several functional tests for technical verification were successfully performed prior to the PoC as

described in the deliverable 6.3.

Figure 8 describes the Semantic Repository architecture used in the PoC. SPARQL is used as an end-

point of the Semantic Repository accessible over HTTP and JENA REST API.



www.episecc.eu

Figure 8: The Semantic Repository architecture

2.3.3. Semantic annotations

For the creation of semantically annotated messages, CIS component Semantic Service was

prototyped and implemented during PoC. Semantic service offers to the end users the following:

entering and storing the end users’ concepts, their description and other properties;

semantic mapping of the end users’ concepts to the EPISECC Taxonomy’s concepts;

creation of semantic annotations (via semantic matching process).

The deliverable 4.3, section 4.2.1, explains in details the use cases of the Semantic Service shown in

Figure 9. The deliverable 5.2 describes the Semantic Service component, called Semantic Box, from

the CIS architecture’s perspective. The conceptual description of the Semantic Service is shown in

Figure 9. The expert helps end users to classify their concepts against the EPISECC Taxonomy and

assigns the SKOS-thes mapping relations, which are stored in the EPISECC Semantic Repository.

During semantic mapping, the expert creates the compound terms from the EPISECC Taxonomy

facets’ values. However, in the fully operational version of the envisaged solution the creation of

compound terms form facets’ values should be performed automatically through the user interface.

These processes should be performed during CIS configuration and prior to the response phase.

During the response phase, CIS software component requests concepts of the end user receiving the

message which semantically match the concepts of the end user sending the message. The request is

performed through the EPISECC Semantic Repository. If needed, in the case not all the semantic

relations are stored in the Semantic Repository, the semantic matching can be extended with the

reasoning algorithm implemented in Apache Jena framework which infers additional semantic

relations and store them in the EPISECC Semantic Repository. Finally, the CIS software component

creates semantically annotated messages. Forthcoming sections describe the implemented Semantic

Service prototype in PoC.



www.episecc.eu

Figure 9: UML Use case diagram s of Semantic Service offered by CIS (deliverable 4.3)

The design shown in Figure 9 proposes that entering of end users’ concepts and classifications

against the EPISECC Taxonomy (Use cases 1, 2 and 3) are performed by an expert, an employee of

the emergency organisation or an external consultant, and prior to the disaster response. The

EPISECC project team, in cooperation with the three end users’ organisations PCRFVG, CNVVF and

MRAS, selected adequate concepts and classified them against the EPISECC Taxonomy. The concepts

and semantic relations were entered into the EPISECC Semantic Repository prototype by the EPISECC

partner using Desktop Protégé.

For the PoC, 248 end users’ concepts were mapped to the EPISECC Taxonomy’s concepts by use of

the SKOS-thes’s properties: ‘has exact match’ and ‘has broader match’. Figure 10 shows an excerpt of

the end users’ concepts and their semantic mappings.

Some examples shown in the Figure 10 are as follows:

CNVVF’s concept ‘Terremoto’ has exact match to the EPISECC Taxonomy concept ’Earthquake’;

CNVVF’s concept ‘Coperture tetti’ has broader match to the EPISECC Taxonomy concept ’Physical

response’;

MRAS’s concept ‘Industrijska nesreča’ has exact match to the EPISECC Taxonomy concept

’Industrial disaster’;

MRAS’s concept ‘Reševanje v gorah’ has broader match to the EPISECC Taxonomy compound

term ’(Rescue of people, Terrestrial)’.

Once the end users’ concepts and their semantic mappings are stored in the EPISECC Semantic

Repository prototype, the Semantic Service can request semantic matching and produce semantic

annotations. For the PoC, the Semantic Service prototype was built including the following:

The Semantic Matching Web Service, and

The Semantic Repository Wrapper Service.



www.episecc.eu

The Semantic Matching Web Service provides a SOAP Web Service API to validate standard messages

and to request semantic matching between end users’ concepts via the EPISECC Taxonomy. The

Semantic Repository Wrapper provides a REST API to convert matching requests from the Semantic

Matching Web Service into SPARQL queries to the EPISECC Semantic Repository prototype. It is based

on the Apache Jena Fuseki service.

Figure 10: An excerpt of end users’ semantic mappings against the EPISECC Taxonomy concepts

During PoC, three end users were using the Semantic Service for creation of semantically annotated

messages: PCRFVG, CNVVF and MRAS. For the particular message exchanged via CIS, the Semantic

Matching Web Service prepared the request for semantic matching including the names of end users

participating in the message exchange and concepts’ terms (labels in SKOS-thes) found in the

message. The Semantic Repository Wrapper Service requested semantic matching between end

users’ concepts (via the EPISECC Taxonomy) by SPARQL queries. Generic example of SPARQL query

for semantic matching is given in the Figure 11. The SPARQL query returns all the concepts from

CNVVF and MRAS which are semantically related by any relation type: exact or broader match.



www.episecc.eu

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>

PREFIX owl: <http://www.w3.org/2002/07/owl#>

PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>

PREFIX skos: <http://www.w3.org/2004/02/skos/core#>

PREFIX skos-xl: <http://www.w3.org/2008/05/skos-xl#>

PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>

SELECT ?alf ?as ?blf ?bs ?clf ?cs

WHERE { ?a skos:inScheme ?as.

?as rdfs:label "CNVVF"@it.

?b skos:inScheme ?bs.

?bs rdfs:label "EPISECC"@en.

?a ?match_type ?b.

?match_type rdfs:subPropertyOf skos:mappingRelation.

?c skos:inScheme ?cs.

?cs rdfs:label "MRAS"@sl.

?c ?match_type ?b.

?a skos-xl:prefLabel ?al.

?b skos-xl:prefLabel ?bl.

?c skos-xl:prefLabel ?cl.

?al skos-xl:literalForm ?alf.

?bl skos-xl:literalForm ?blf.

?cl skos-xl:literalForm ?clf}

Figure 11: SPARQL query executing semantic matching over the EPISECC Semantic Repository

Figure 12 shows the result of the above SPARQL query. Due to paper size limitations, the match types

are not shown. For example, the CNVVF’s concept “RI/MP” has ‘broader match’ relations to two

MRAS’s concepts: “Orodno vozilo” and “Tehničko vozilo”.

Figure 12: SPARQL query result for semantic matching between CNVVF’s and MRAS’s concepts



www.episecc.eu

{

"concepts": [

{

"concept_id": "http://www.episecc.eu/ifb/ifb_0465",

"concept_value": "Assist. Popolazione, trasporti viveri,

accesso aree emergenza",

"concept_equivalences": [

{

"concept_value": "Pomoc prebivalcem",

"match_type": "broadMatch"

}

]

},

{


"concept_value": "Emergenza Protezione Civile",


{

"concept_value": "Civilna zascita",

"match_type": "exactMatch"

}

]

},

{


"concept_value": "Messa in sicurezza serbatoi GPL",


{

"concept_value": "Zavarovanje",


}

]

},

{


"concept_value": "Recupero beni privati e pubblici",


{

"concept_value": "Okrevanje",


}

]

},

{


"concept_value": "USAR",


{

"concept_value": "Iskanje in reševanje",


}

]

}

],

"src_taxonomy": "CNVVF",

"dst_taxonomy": "MRAS",

"translation_stats": {

"concepts_total": 18,

"concepts_translated": 5,

"concepts_untranslated": 13,

"exact_matches": 1,

"broad_matches": 4,

"translation_accuracy_percent": 13.333333333333337

}

}

Figure 13: Result of the semantic matching request done by SPARQL over the EPISECC Semantic Repository


http://www.episecc.eu/ifb/ifb_0465






www.episecc.eu

The result of the SPARQL query is further processed and structured as shown in the example in the

Figure 13. The end user sending the message (source of the message) is denoted as “src_taxonomy”,

which corresponds to CNVVF. The end user receiving the message (destination of the message) is

denoted as “dst_taxonomy”, which in this example is MRAS. The names of end users correspond to

the names of Concept Schemas stored in the EPISECC Semantic Repository prototype. Five CNVVF’s

concepts were semantically matched with MRAS’s concepts:

"Assist. Popolazione, trasporti viveri, accesso aree emergenza" has broader match in "Pomoč

prebivalcem";

"Emergenza Protezione Civile" has exact match in "Civilna zaščita";

"Messa in sicurezza serbatoi GPL" has broader match in "Zavarovanje";

"Recupero beni privati e pubblici" has broader match in "Okrevanje"; and

"USAR" has broader match in "Iskanje in reševanje".

The solution includes statistics of semantic matching, which is generated and shown at the end of the

SPARQL result (Figure 13). This could be useful for the end users to improve their semantic

interoperability within the CIS and see whether they have included relevant concepts into the

Semantic repository.

The CIS software component creates semantically annotated messages based on the semantic

matching results. The examples of the semantic annotations extracted from CAP message sent by

PCRFVG to MRAS during the PoC are following:

<sender>PCRFVG</sender>

<sent>2017-05-11T10:52:56+02:00</sent>

………

<senderName>Protezione Civile Friuli Venezia Giulia</senderName>

………

<value> Situational report - {Prepovedano:broadMatch} -

{Pozor:broadMatch} - {Hitrost pozara:broadMatch}</value>

………

<value> Total affected - {Stevilo prizadetih:exactMatch}

(Actually affected, property) - {Porusene stavbe:broadMatch} Earthquake -

{Potres:exactMatch}</value>

………

<value> Rescue of people - {Resevanje oseb:exactMatch} Search

and rescue - {Iskanje in resevanje:exactMatch} </value>

2.3.4. Evaluation panel

As described in the deliverable 6.3, from the evaluators’ point of view the semantical perspective was

very well addressed within the demonstration. During the evaluation panel, a separate part was

dedicated to the semantics of the CIS solution, and the approach with semantic annotation was



www.episecc.eu

discussed. However, the comments were not related to the particular concepts, but to the whole

idea and potential problems this concept may face in the implementation. The questionnaire offered

to the panellists relates to the both overall functionally of the CIS solutions and single detailed

functionalities and does not contain particular questions on semantics. However, it implicitly gives

impression on the semantic repository’s functionality and Taxonomy, as well. As elaborated in the

deliverable 6.3, both PoC and evaluators’ statements confirmed that the connection to the CIS offers

multiple benefits such as better understanding of information provided by foreign organisations

through semantic annotation.

The analysis of the evaluators’ comments, gathered during the evaluation panel, is given the Table 4.

Table 4: Evaluators’ suggestions and reflections to them

Evaluators’ suggestions Reflection to the suggestion

You need keywords, which are exact matched.

This system should save time. With keywords you

can save time. If you have time you can input

more terms, but then you have the problem that

the system will be very big.

The usage of keywords could certainly improve

semantic interoperability. Generally speaking, the

EPISECC Semantic Repository is created for unknown

users, but if some users agree on this and establish a

set of keywords representing certain concepts they

can also be mapped to the Taxonomy and used in

messages. The EPISECC solution does not require users

to use common concepts as it is meant to serve

various types of practitioners from humanitarian to

technical and at all decision levels. Anyhow, the

EPISECC Taxonomy is built as common, overlapping

structure, based on the concepts taken from the

various standards and other types of documents, thus

it is already a kind of collection of usually used

concepts, having terms in English that may be offered

as keywords to the end users.

In Austria we have a standard (SKKM). I think this

is also a standardisation thing when it comes to

bigger structures.

I think we need some kind of a basic standard for

everyone. I think it is really necessary. There is a

lot of terms which do not find their way into

standards

The EPISECC Taxonomy, Semantic Repository and

accompanied services are designed to overcome

difficulties related to mutual understanding,

particularly across different languages. The

standardisation is up to end users to agree upon

defining one. If some of the CIS users would like to use

common standard it should be entered into

Repository and mapped to the Taxonomy. Therefore,

whenever end users using standard communicate to

the other CIS users their concepts will be annotated.

There are certain standards for floods, for many

things there are standards.

As explained in deliverables 4.1 and 4.2, the EPISECC

Taxonomy has been built on existing standards used

by various organisations involved in disaster response



www.episecc.eu


and thus it represents intersection of concepts found

in them. However, since the Taxonomy is a living

structure, the analysis and inclusion of emerging

standards is a part of the future development process.

You have also the problem of spelling. It is

important to agree on a common definition.

The spelling problem is certainly a challenge in the

further development od the solution. The problem is

solved in cases when end users crate messages from

predefined concepts already embedded in interfaces

of tools they use. The more complex situation is when

they type either parts or whole messages directly into

their tools. In these cases, a spell checker may be

implemented as a part of the message search engine

within EPISECC Semantic Box.

For example a standard is what kind of weather

data you use. It is very important that everybody

has the same understanding.

The proposed solution presumes that end users

always use their own concepts, so there is no need to

be worried about the understanding of their own

words while sending messages or while reading them

in semantic annotations. Nevertheless, this issue may

arise during the mapping process when end users

classify their concepts against the EPISECC Taxonomy.

At that point, the descriptions of Taxonomy’s concepts

are crucial and further attention will be paid in a sense

that they should be both short and clear, always using

world wide common standards.

You should not have single vehicle terms in your

taxonomy, because LEMA creates the whole

picture.

The LEMA needs this information; we have to

agree on a basis.

LEMA is not making micro management. LEMA

creates the big picture.

The suggestion not to include a single vehicle terms in

the Taxonomy because LEMA creates the whole

picture has already been considered, as Advisory

Board members previously suggested not to go into

details with equipment. To this end, the informal rule,

particularly concerning concepts related to the

equipment, to stay as generic as possible is set and

will remain. However, this could be challenging since it

is sometimes hard to distinguish between generic

categories and particular manufactures’ types of

equipment, which implies strong involvement of

relevant practitioners.

To take into account that the translation has to

be exact.

The exact translation of the messages is a real

challenge. However, for the time being, semantic

mechanisms for preforming automatic translations are

not reliable enough and could provide inaccurate

results, which might be dangerous during disaster



www.episecc.eu


response, particularly when people and goods are

endangered. Therefore, as elaborated in deliverables

4.2 and 4.3, the solution with semantic annotations

based on common concepts organised as taxonomy is

proposed, keeping messages in original language. This

solution with semantic annotations may also serve for

the organisations which use the same language but

different terms for same concepts. However, it would

be good to have as much exact concepts as possible

during the mapping and consequently matching

processes, which obviously depends on the

comprehensiveness of the Taxonomy. Therefore,

future development should go towards finding the

most common concepts and including the most

possible set of standards and other relevant

documents.

There is a project called 112. You can put

warning on the one side.

The semantics is related to the first responders’

communication during the first hours if the disaster

response. Therefore, it does not include general

semantics from third parties like citizens and other

organisations. The concepts and semantic repository

serves only those who are connected into CIS.

Consequently, warning messages generated outside

CIS are not in the focus of the solution.

Even though the evaluators’ suggestions are quite general and do not tackle the particular items of

the solution, they are considered and included in the improvements described in the Chapter 3 and

will be certainly helpful as guidance to the further development of semantic components.

3. Analysis and improvements

Following the continuous research on the common concepts used in the disaster response phase as

well as reflections from AB members and external evaluators the project’s semantic structures have

been permanently improved. This chapter provides thoughts and actions in attempts to meet the

end users’ requirements related to semantic interoperability and improve project’s solution.

The particular attention has been paid to the Taxonomy and Ontology model as ever changing

structures. This document delivers their updated versions based on research and validation within

the EPISECC project.



www.episecc.eu

Data model for the Semantic Repository was continuously tested, as CIS components were

prototyped. Besides technical verification, being a constituting component of CIS Semantic Service,

the data model was indirectly presented to the end users. The following sections describe and

comment use of data model during PoC.

3.1. EPISECC Taxonomy

The concepts provided by the end users are analysed in the context of the Taxonomy’s purpose and

suggestions collected during the communication with AB members and the PoC. The newly obtained

concepts were mapped to the Taxonomy, as this process usually shows whether there is a need for

the taxonomy improvements in terms of adding more concepts or changing the structure. This

process is sensitive, cannot be precisely or automatically measured by metrics, and depends on

expert’s judgement on quality of the concepts’ semantic relations. Even though the sample of the

mapped concepts is not evenly distributed over both types of end users and decision levels, some

numbers may be indicative for the analysis. Roughly 30% of the concepts were classified as exact

against the EPISECC Taxonomy’s concepts or compound terms. This percentage depends on the type

of the concepts obtained and if they are related to the particular type of the equipment like vehicle

they are mainly classified as non-exact to the Taxonomy’s concepts having usually broader meaning.

The obtained concepts related to the processes or disasters have exact concepts in the Taxonomy.

As elaborated in deliverables 4.1 and 4.2, the EPISECC Taxonomy has not been built only as a sole

structure but also as a tool for semantic interoperability in the CIS solution. The EPISECC Taxonomy is

a part of the EPISECC Semantic Repository, which is described in detail in the deliverable 4.3, and it

serves as an interface between end users’ concepts regularly and frequently used during the disaster

response phase. Therefore, the analysis and further improvements are considered in the context CIS

solution as whole.

Newly obtained concepts were analysed as follows:

in relation to their use in the disaster response phase,

their potential to be mapped to the EPISECC Taxonomy.

Based on the abovementioned decision for the Taxonomy improvements in terms of better

adjustments to the universe of discourse, consequent actions described below have been repetitively

performed. Herein, the main ideas from the improvement process are highlighted and described.

The modelling started by finding the main facets which describe “a response to a critical event”. It is

concluded that there are three crucial perspectives from which the universe of discourse could be

perceived:

what kind of event is happening,

who is dealing with the consequences, and

what means are available to respond to the situation.

Consequently, three main facets were created: disaster, organisation and capacity. Even though

during the initial internal validation of the Taxonomy, it was agreed that specific location and time



www.episecc.eu

are not needed as parts of the EPISECC Taxonomy, since they are generic concepts not exclusively

dedicated to “a response to a critical event”, the analysis of the messages and for the sake of better

understanding they are included as additional main facets to complete the universe of discourse

within the Taxonomy:

where the event is happening, and

when the event is happening.

The additional two main facets are added: time and locus. As described in the deliverable 4.2 the

generic sources of such concepts, like upper ontologies, were examined: SWEET ontology [1] and

W3C Time ontology [2]. It is realised that introducing the concepts from these models is not suitable

for the purpose of very dedicated EPISECC Taxonomy. Therefore, based on the analysis of the end

users’ requirements, distinct values and further decomposition of Time and Locus facets are

developed.

The facet Time is presented with two values (concepts) since there are internationally recognised and

used units, which are understandable to the end users speaking different languages. Oppositely,

facet Locus has more values since it appeared that a relative position has same importance as the

particular location in space. Moreover, the character and shape of space or a position in space are

also included as found to be important for first responders’ communication.

The majority of newly collected concepts, which are used in the dry run exercise and the PoC are

manly related to the operational and only partially to the tactical level and are used by technical

organisations (mountain rescue services and fire fighters). The lack of the possibility to gather more

concepts related to the strategic and tactical levels as well as to the humanitarian organisations point

of view is partly substituted with direct contacts with Advisory Board member from Austrian Red

Cross prior to the PoC. Generally speaking, as expected, the newly obtained concepts reflect the

decision level of the providers. The concepts collected from the firefighters are mainly dedicated to

the machinery and specific operations. The concepts obtained from Red Cross representative are

dedicated to the high level decision making process and some are outside the response phase but

indicate the communication context at the strategic level. Furthermore, the analysis shown that the

information obtained from end users during the dry run are already covered and in a line with the

analysis already performed and described in the deliverable 4.1.

Regarding the Taxonomy’s structure, the origin of the facet Application is relocated, from the

Equipment to the Capacity, since it is realised that application could be a characteristic of any kind of

capacities. The deliverable 4.2 discussed the meaningfulness of the concept Competence as it has

only one level of sub-concepts. After the analysis, the concept is kept since the concepts provided by

the person from a strategic level in Red Cross indicate that high disaster management level may use

it in the classification (mapping) process. However, this concept may be further developed if there

will be a need for more specific sub-concepts.

In the deliverable 4.2 a concern related to the balancing Taxonomy’s structure was expressed,

meaning that main concepts or facets preferably have equal numbers of sub structure-levels. During

the implementation there were no problems related to this issue, and certainly should the Taxonomy



www.episecc.eu

and mapping process be implemented in fully developed interface, using indexing or similar

techniques, this won’t pose any problems to the users.

Regarding the remark posed during the internal validation (deliverable 4.2) related to the possibility

that consequences of a disaster could be both in the list of impacts and in specific event types, the

messages used during the validation process contained consequent concepts. They were mapped to

the Taxonomy as compound terms (for ex. values of facets Circumstance and Object type) and

adequately annotated. Therefore, there wasn’t necessity to change the Taxonomy accordingly.

During the conversation with operational types of end users it appeared that end users are not much

familiar with the term mission for the concept related to the activities during the response phase and

they prefer the term mission. Since the term process is more generic it is kept and the term mission

is added as an additional label to this concept as it is preferred in the end users community.

Some equipment related to the disaster response activities of the humanitarian organisations has

been added as appeared to be important to the Red Cross. Regarding other end users, some

concepts related to the technical equipment are also added, as well as some types of processes.

The difficulty in identifying the exhaustiveness of in the facets’ values or sub-concepts still exists. The

decision to have Taxonomy as generic as possible helps both facets and concepts to be as exhaustive

as possible. However, whenever the values or sub-concepts determine the types of very particular

“thing” like equipment, the non-exhaustiveness may occur. Therefore, the principle of non-exact

instead of boarder classification against EPISECC Taxonomy may be introduced so the end users’

concepts could be mapped not only to the more generic concept but also to the concept that is quite

similar to theirs. Introducing, more types of mapping relations may also be an option, but as it was

realised during the discussion with them, such solution can be perceived as complex and retract

them from adopting the CIS solution without significant improvements in the semantic

interoperability. This is very challenging issue and has to be profoundly validated with end users.

The updated version of the Taxonomy is given in the Annex II.

3.2. Data base model

The data model is created taking into account the EPISECC database roles as follows:

to serve as Semantic Repository of CIS,

to support storage of various semantic structures,

to support semantic mapping and semantic matching applications in CIS,

to support adding additional participants as required (deliverable 4.3).

The EPISECC project team’s decision about repository’s design was to reuse Simple Knowledge

Organisation System – thesaurus (SKOS-thes) as the most suitable data model for the EPISECC

Semantic Repository. The representation of the repository’s elements in SKOS-thes model is defined

and described in the deliverable 4.3. SKOS-thes semantic relations are used to represent

classification of the organisations’ concepts against the EPISECC Taxonomy’s concepts.



www.episecc.eu

Validation of the data model for the EPISECC Semantic Repository should prove that the proposed

data model meets the needs of end users besides fulfilling the requirements given by the design. As

data model represents a technical design for an element of CIS and is not solely used by the end

users, the validation process should include data model implementation together with deployment

of the services offered to the end users. Thus, the Semantic Service prototype (called Semantic Box)

was built including the Semantic Repository prototype as its constituting part. During the PoC, the

Semantic Service was used and the Service and underlying data model could have been validated.

Forthcoming sections analyse and propose improvements of the data model used for the EPISECC

Semantic Repository prototype.

The EPISECC Semantic Repository prototype was loaded with the EPISECC Taxonomy, selected sets of

concepts from end users and semantic mappings of the end users’ concepts against the EPISECC

Taxonomy’s concepts.

The EPISECC Taxonomy required a complex data model because its structure contains faceted

hierarchies of concepts. The first implementation and testing of the data model were done during

the design phase described in the deliverable 4.3. The results showed that SKOS-thes model is

adequate for storing faceted hierarchies. Compound terms were used in PoC, and SKOS-thes models

them with the two classes ‘Compound Equivalence’ and ‘Split Non Preferred Term’, and with the two

properties ‘Plus Use Term’ and ‘Plus Used For Term’. That strucure is complex and requires more

complex processes of semantic mapping and matching. To oversome that complexity, compound

terms were entered as individuals of the class Concept and treated as any other individual of that

type. For example, a concept composed of the facet’s values ‘Actually affected’ and ‘Property’ is

entered as an individual of the class Concept, labelled with (Actually affected, property). Thus,

semantic matching process required only class Concept. There are no other processes that needed

more complex structure for the compound terms in the PoC.

End users’ concepts used in PoC are not organised hierarchically or in any other structure. End users

provided lists of concepts’ descriptions and one or more labels (terms). The SKOS-thes basic

elements were needed to store end users’ semantics.

As regards semantic relations between the end users’ concepts and the EPISECC Taxonomy, so far it

was proven that two distinctive types are needed and the SKOS-thes properties “has exact match”

and “has broader match” meet this requirement. If needed, the SKOS-thes standard offers more

types of properties that may be used for semantic relations such as “has close match” or “has

narrower match”. The application of semantic relations’ types for the mapping process as well as

their implications to the matching results and semantic annotations are discussed in Chapter 4.2.

Although the process of data entering into the EPISECC Semantic Repository was not performed by

the end users, the PoC showed that the proposed data model is adequate for storing the EPISECC

Taxonomy and end users’ concepts, as well as for serving semantic mapping and matching. The

external evaluators’ reflections on the project’s semantic solution and consequently on semantic

annotations are positive, as described in the deliverable 6.3.



www.episecc.eu

The PoC showed that the proposed data model is adequate for storing the EPISECC Taxonomy and

end users’ concepts, as well as for serving semantic mapping and matching. For the implemented

processes of semantic mapping and matching, modelling compound terms as individuals of type

Concept satisfied needs during PoC. The future users could decide to use more complex structure

proposed by the SKOS-thes model if needed.

The Data model for the EPISECC Semantic Repository was validated and turned to be fully satisfying ,

therefore no further improvements were implemented in the frame of the project.

3.3. EPISECC Ontology model

The EPISECC Ontology model is developed to serve creation of common operational picture with

dynamic spatial information, showing the evolution of the situation in affected area and locations of

resources. The ontology scope is defined by the EPISECC use case, the scenario designed for the PoC

described in deliverable 6.1. The conceptual ontology model is developed including a subset of the

EPISECC Taxonomy and references to one upper and two domain ontologies. The ontology schema is

created by using formal languages Resource Description Framework Schema (RDFS) and Ontology

Web Language (OWL) by Protégé Desktop. The logical consistency of the model is checked by

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

individual belongs to two disjoint classes. The deliverable 4.4 describes in details the EPISECC

Ontology model and its first implementation.

The development of an ontology model is an iterative process and thus, the first version of the

EPISECC Ontology model was validated and revised based on the PoC’s use cases described in the

deliverable 6.3. The applied approach for validation was to create competency questions the model

should answer correctly [3]. For each competency question, the Ontology model’s elements were

analysed and further improvements were proposed. Populating the Ontology model with end users’

data was not necessary since the end users have been permanently involved in the improvement of

the EPISECC Taxonomy, which is a constituting part of the Ontology model. Consequently, the

improvements embedded in the EPISECC Taxonomy have been propagated to the Ontology model.

The following paragraphs explain the process of validation and describe the proposed improvements

of the EPISECC Ontology model.

The competency questions should encompass the situational and operational data exchanged among

the end users during the PoC. The EPISECC scenario and three use cases were the basis for the

development of the competency questions. Participating end users and description of use cases’

processes are given in the deliverable 6.3. Herein, a brief description of the use cases and derived

competency questions is given.

The Use Case 1 description is as follows: “PCRAFVG as the local emergency management authority

receives early warnings, disaster related data as well as situation assessment information from

national responders and prepares a first common operating picture.” (deliverable 6.3).



www.episecc.eu

For the creation of common operation picture by the PCRAFVG, the EPISECC Ontology model should

answer the following competency questions:

Where and when did the disaster happen, what is the type and intensity of the disaster?

Where are the damages, when did they happen, and what are the types of the damages?

Where are injured people, when were they injured, and how many people are injured or dead?

Where and when are operations executed, who executed operations, what are the types of

operations?

Where are the resources, when are they needed, what are the types and capacities of resources

which have been urgently needed?

The Use Case 2 description is as follows: “PCRAFVG as the local emergency management authority

triggers help from neighbouring countries Austria and Slovenia.” (deliverable 6.3).

The competency questions derived are:

Where are available resources, when are they needed, what are the types and capacities of the

available resources and what response units do resources belong to?

Where and when do operations happen, what are the types of operations and what response

units are operations assigned to?

The Use Case 3 description is as follows: “First responders collaborate in on-site response.”

(deliverable 6.3).

The competency questions derived are:

Where are the damages, when did they happen, and what are the types of damages?

Where are injured people, when were they injured, and how many people are injured or dead?

Where and when are operations executed, who executed operations, what are the types of

executed operations?

Where are the resources, when are they needed, who needs the resources, what are the types

and capacities of needed resources?

The competency questions derived from the Use Case 1 and Use Case 3 are partially overlapping

because the both use cases include retrieving the situational reports and requests for the resources

but from different end users. By omitting the overlapping questions, the final list of eight

competency questions is obtained and presented in Table 5.Table 5: Ontology model’s elements and

improvements

No. Competency question Ontology model’s elements

Class/Subclass Property

1 Where and when did the disaster happen, what is the type and intensity of the disaster?

Dynamic data/Situational data/ Disaster /Earthquake

‘has spatio-temporal part’

‘has epicentre’

‘has magnitude’

Improvements: none



www.episecc.eu



2 Where are the damages, when did they happen, and what are the types of the damages?

Dynamic data/Situational data/ Disaster


‘has affected object’

Disaster object/People

…/Environment

.../Property

…

Dynamic data/Situational data/ Damage data


Improvements:

Class ‘Disaster object’ needs properties describing location and time and it should be placed as subclass of ‘Dynamic data’/‘Situational data’.

Add properties: ‘has size’, ‘has number’ and ‘has value’ for describing damages.

3 Where are injured people, when were they injured, and how many people are injured or dead?

Dynamic data/Situational data/Affected people data/ Casualties /Injured with high priority

…/Injured with low priority

…/Killed


Improvements:

Add property: ‘has number’ for describing casualties.

4 Where and when are operations executed, who executed operations, what are the types of operations?

Dynamic data/Operational data/ Process/Command & control

…/Physical response/Extinguishing fire

…/…/Search for people

….

…/Resource management/Providing supplies to first responders

…/…/Providing supplies to people


‘has status’

‘has priority’

‘has capability’

Organisation

Improvements:

Add object property ‘executes’, the inverse property of ‘executed by’ (property relating ‘Organisation’ and ‘Process’).



www.episecc.eu



5 Where are the resources, when are they needed, what are the types and capacities of resources which have been urgently needed?

Dynamic data/Operational data/ Resource

…/Animal

.../Financial

…/Human

…/Institutional

.../Physical/

…/…/Equipment

…/…/Infrastructure

…


‘has status’

‘has quantity’


Dynamic data/Operational data/ Process


‘uses’

‘has priority’

Process priority

Improvements:

Add individuals ‘high priority’, ‘medium priority’ and ‘low priority’ and redefine ‘Process Priority’ class to be equivalent to the list including these individuals.

6 Where are available resources, when are they needed, what are the types and capacities of the available resources and what response units do resources belong to?


…/Animal

…/Financial

…/Human

…/Institutional

…/Physical/

…/…/Equipment



‘has status’

‘has quantity’


Organisation ‘has available’

Status

Improvements:

Add individuals ‘available’, ‘needed’ and ‘in use’ and redefine ‘Status’ class to be equivalent to the list including these individuals.



www.episecc.eu



7 Where and when do operations happen, what are the types of operations and what response units are operations assigned to?

Dynamic data/Operational data/Process …/Command & control

…/Physical response/ Extinguishing fire


….

…/Resource management/ Providing supplies to first responders



‘uses’

‘executed by’

Organisation

Improvements:


8 Where are the resources, when are they needed, who needs the resources, what are the types and capacities of needed resources?

Dynamic data/Operational data/Resource

…/Animal

.../Financial

…/Human

…/Institutional

.../Physical/

…/…/Equipment



‘has status’

‘has quantity’


Dynamic data/Operational data/Process/

‘uses’

‘executed by’

Organisation

Improvements:


For each competency question, the EPISECC Ontology model’s elements are analysed and further

improvements are proposed. The analysis includes the following:

identification of the EPISECC Ontology model’s elements (classes and properties) available for

getting answers on the competency questions;

proposal of the improvements for the EPISECC Ontology model.



www.episecc.eu

The findings are given in the Table 5. The class ‘Dynamic data’ provides data on a location and time

for all the subclasses and thus answers the questions: ‘Where?’ and ‘When?’. Location and time are

provided by object property ‘has spatio-temporal part’ and related individual, a member of class

‘Spatio--temporal part’.



www.episecc.eu

Table 5: Ontology model’s elements and improvements



1 Where and when did the disaster happen, what is the type and intensity of the disaster?

Dynamic data/Situational data/ Disaster /Earthquake


‘has epicentre’

‘has magnitude’

Improvements: none

2 Where are the damages, when did they happen, and what are the types of the damages?

Dynamic data/Situational data/ Disaster


‘has affected object’

Disaster object/People

…/Environment

.../Property

…

Dynamic data/Situational data/ Damage data


Improvements:

Class ‘Disaster object’ needs properties describing location and time and it should be placed as subclass of ‘Dynamic data’/‘Situational data’.

Add properties: ‘has size’, ‘has number’ and ‘has value’ for describing damages.

3 Where are injured people, when were they injured, and how many people are injured or dead?

Dynamic data/Situational data/Affected people data/ Casualties /Injured with high priority

…/Injured with low priority

…/Killed


Improvements:

Add property: ‘has number’ for describing casualties.

4 Where and when are operations executed, who executed operations, what are the types of operations?

Dynamic data/Operational data/ Process/Command & control

…/Physical response/Extinguishing fire


….

…/Resource management/Providing supplies to first responders



‘has status’

‘has priority’


Organisation



www.episecc.eu



Improvements:


5 Where are the resources, when are they needed, what are the types and capacities of resources which have been urgently needed?


…/Animal

.../Financial

…/Human

…/Institutional

.../Physical/

…/…/Equipment


…


‘has status’

‘has quantity’


Dynamic data/Operational data/ Process


‘uses’

‘has priority’

Process priority

Improvements:

Add individuals ‘high priority’, ‘medium priority’ and ‘low priority’ and redefine ‘Process Priority’ class to be equivalent to the list including these individuals.

6 Where are available resources, when are they needed, what are the types and capacities of the available resources and what response units do resources belong to?


…/Animal

…/Financial

…/Human

…/Institutional

…/Physical/

…/…/Equipment



‘has status’

‘has quantity’


Organisation ‘has available’

Status



www.episecc.eu



Improvements:

Add individuals ‘available’, ‘needed’ and ‘in use’ and redefine ‘Status’ class to be equivalent to the list including these individuals.

7 Where and when do operations happen, what are the types of operations and what response units are operations assigned to?

Dynamic data/Operational data/Process …/Command & control

…/Physical response/ Extinguishing fire


….

…/Resource management/ Providing supplies to first responders



‘uses’

‘executed by’

Organisation

Improvements:


8 Where are the resources, when are they needed, who needs the resources, what are the types and capacities of needed resources?

Dynamic data/Operational data/Resource

…/Animal

.../Financial

…/Human

…/Institutional

.../Physical/

…/…/Equipment



‘has status’

‘has quantity’


Dynamic data/Operational data/Process/

‘uses’

‘executed by’

Organisation

Improvements:


The above improvements together with the improvements propagated from the EPISECC Taxonomy

were incorporated in the final EPISECC Ontology model and given as OWL file in the Annex III. Beyond



www.episecc.eu

the EPISECC project lifetime, the changes of the EPISECC Ontology model are foreseen in the further

development of the EPISECC Taxonomy and in the extension of the EPISECC Ontology scope, which is

now limited to the EPISECC use case.

4. Conclusions

The evaluation of the project’s outcomes related to the semantics revealed the necessity for their

usage in disaster management, particularly in the response phase. The essential of the development

of semantic structures is to be used for better interoperability in general. There is an obvious need

for automatic services that help people to mutually understand themselves seamlessly, without any

barriers. As the language barrier is still the immense obstacle, the urgency for development of so-

called automatic translation seems the priority. However, at this moment, this is far from achievable

since human behaviour contains very complex semantics, which cannot be easily predicted and put

into codes and procedures. So far, this may be overcome by extensive standardisation, as everyone

may use the same terms for the same concepts and terms may be in different languages as the

translation of terms is straightforward. However, this is not easy since countries and organisations

have their legacies and create their own world of terms and standards, despite worldwide

standardisation efforts. Therefore, the research in this project is oriented towards bridging the gap

between different organisations, coming from different countries and backgrounds, by building

semantic structures which serve as an interface between them. Therefore, there is no need for first

responders to change the legacy structures or to adjust to a certain standard.

This chapter analysis the relevance of the semantic structures developed within the EPISECC project

and explains how they may be further developed through activities beyond the project’s lifetime.

4.1. Significance and perspectives of the models

The semantic models developed within the project are based on existing semantic concepts, which,

put together, present the novel semantic interoperability approach in disaster response

interoperability. Moreover, the Taxonomy and accompanied Ontology model develop a concept of a

common ground towards standardisation.

The ever-existing need for more efficient and efficacious communication between first responders,

particularly in cross-border situations or international scope of a disaster, endorses the approaches

undertaken in the project. According to the feed back from the AB members and external evaluators

the objectives of the taxonomy structure, accompanied with data model and ontology for EPISECC

use case, set up at the beginning of the project are still quite relevant. Looking at published papers, it

is apparent that topics related to the interoperability during the disaster and emergency response

and situational awareness which is closely related to it, are still actual. Fore example, in two recent

papers D. da Silva Avanzi et al. [4] assess the disaster management domain through interoperability

concerns and barriers and Seppänen and K. Virrantaus [5] suggest the method for defining the critical



www.episecc.eu

information and the relevant information quality elements required for the shared situational

awareness in the disaster response.

By introducing semantic annotations during the message exchange between first responders the

solution fosters communication and mutual understanding. The Taxonomy is built on variety of

inputs from end users and thus presents a common structure understandable by practitioners

despite of different culture, practice, expertise etc. By structuring data and processes the Taxonomy

influences the development of the Common Information Space.

The Taxonomy’s faceted structure is a model of relevant concepts used during the disaster response

phase, which is easy to search. This structure makes it suitable for the standardisation process.

Semantic repository inferring ability fully supports information interoperability during a mission,

when several end users are involved, and helps them to better understand and monitor the situation,

as well as make adequate and timely decisions.

Terms and standards used by organisations are ever emerging and the semantic models developed

within the project should cope with that. Introducing the Semantic Repository as a central place for

storage of semantic descriptions has a significant implication because semantic descriptions become

independent of application codes and there are no needs for upgrading tools every time semantics

change. Use of the RDF database model for the Semantic Repository made that central place

distributed over the web what brings a new perspective for the maintenance: semantic descriptions

now can be maintained by common effort of all end users.

The third semantic structure is the EPISECC Ontology model, enriching semantic descriptions of the

EPISECC Taxonomy towards semantics for the spatial and temporal concepts. The EPISECC Ontology

model describes the EPISECC use case as a model of domain knowledge with references to the upper

ontologies thus enabling dynamic merging of data. The intention is that spatio-temporal data coming

to the CIS from different end users could be classified automatically and merged into one operational

picture. The significance of introducing ontology model is that ad-hoc users could participate in

shared situational awareness during disaster response. While using the Semantic Repository, only a

priori end users, users who have already entered their concepts and semantic mappings, can get

semantically annotated messages. Ontology model enables that semantic descriptions are exchanged

together with data and thus ad-hoc users can participate with their data in the common operational

picture.

4.2. Follow-up research

There are evidently many directions for further research in semantics for the disaster management.

Herein, the follow-up activities and research directions related to the main project’s semantic

structures are envisaged.

There are several possibilities for development of the EPISECC Taxonomy beyond the project’s

lifetime. Taking into account that the Taxonomy may be treated within or outside the EPISECC CIS

solution, the research aspects go towards the following:



www.episecc.eu

improvement toward more flexible structure;

finding more concepts from ever emerging semantic structures like standards, dictionaries,

taxonomies or similar documents;

expanding its universe of discourse towards other phases in disaster management cycle and/or

emergency management concepts.

The abovementioned activities are intended to be continued by the research organisations of the

project’s consortium. There is also a possibility is to keep maintaining the Taxonomy working

together with other projects dealing with disaster or emergency management like, for example, with

activities of the DRIVER+ project. The project analysis regulatory frameworks and procedures

including standardisation.

The project’s activities in CEN/WS TER-CDM - Terminologies in crisis and disaster management can be

the basis for further enhancement of the Taxonomy. The workshop includes analysis of relevant

national and international standards and other terminologies, since they contain terms and

definitions, which are usually overlapping, often confusing and in some cases partially contradicting.

The terms and accompanied descriptions are compared regarding their sources, user groups and

intended domain of applications. The CEN workshop agreement is described in details in the

deliverable 9.1.

The further challenging issue related to semantic annotations is the improvement of mapping and

matching processes. As already mentioned in the Chapter 2 there is a question about how many

types of mapping relations between end users’ concepts and the Taxonomy should be introduced.

The solution with more than two relation types, as it is in the actual solution, should be examined in

order to see whether it provides more clarity and trustworthiness in this process. Actually, the

answer is in the final output of the matching process, namely the procedure that derives semantic

annotations accompanied with the type of relations between sender’s and receiver’s concepts. The

research in the project comes up with the conclusion that relations that are results of the matching

process should be simple and clear: either concepts match exactly or they do not have exact

matching. This conclusion underpins the fact that during the response phase semantic annotations

having only two different types of matching makes their understanding quick and easy since first

responders do not have time to cope with more types of semantic relationships. Therefore, having

two types of matching where exact match is the result if and only if both concepts are mapped as

exact to the same Taxonomy’s concept, and all other situations result in non-exact matching

indicates that two types of mapping relationship are enough: exact and non-exact. Non-exact

corresponds when the end users’ concept is related the Taxonomy’s concept either hierarchically

(broader or narrower) or by certain semantic similarity in term of equivalency or they can be

associated in some way. If the research show that more types of relationships between end users’

concept and Taxonomy are needed, they may be defined in accordance with the ISO 25964-2:2013

[6] as a step toward standardisation. Undoubtedly, further research in Taxonomy’s concepts should

go towards achieving more contacts with practitioners outside AB members as well as at strategic

and tactical level.



www.episecc.eu

Semantic Repository uses SKOS-thes model which is based on two standards: the SKOS standard for

representing knowledge over the computers network [7] and ISO 25964 standard for linked thesauri

[6]. This opens possibilities for future use of the Semantic Repository by communities outside the CIS

end users via Linked Open Vocabulary, shared and linked open access vocabularies on the web [8].

Further developments of the Ontology model could follow several directions such as:

incorporating further development of the Taxonomy as a constituting part of ontology,

expanding the Ontology model’s scope,

building prototypes and testing with data coming from ad-hoc users.

The upgrades of the EPISECC Taxonomy should be considered by the EPISECC Ontology as described

in the deliverable 4.4. Upgrading process asks for involvement and common agreement of all CIS’s

participants, thus it is performed periodically. Therefore, it is not considered that CIS should develop

a system for automatic propagation of changes which needs highly complex expert system. Instead,

the changes should be considered by an ontology expert and thoughtfully implemented as changes

to the EPISECC Ontology model classes and properties.

Response to a critical event is a complex human domain encompassing response actions taken in

various spatial, technical, organisational and legal environments. In EPISECC project, the Ontology

model’s scope was limited to the EPISECC scenario and use cases with the focus on spatio-temporal

data. Further development of the Ontology model, as an example, could include workflow of

undertaken actions during the response or make references to other domains’ ontologies such as

sensors data. Testing with ad-hoc users and their data should further approve use of ontology

models for disaster management, e.g. merging data from social media into a common operational

picture.

There are many research topics covering use of ontology models and semantic web technologies for

the disaster management. The most challenging issues cover unrealised semantic web technologies

which have to ensure and verify that data are coming from trusted source. The new paradigm of

including ad-hoc participants and their data during disaster management asks particularly for trusting

the information.



www.episecc.eu

Bibliography

[1] NASA, “SWEET ontology”, 2014. [Online]. Available: https://sweet.jpl.nasa.gov. (last accessed

22 August 2017)

[2] W3C, “Time Ontology in OWL”, 2006. [Online]. Available: https://www.w3.org/TR/owl-time/.

(last accessed 22 August 2017)

[3] D. Allemang and J. Hendler, “Semantic Web for the Working Ontologist”, Elsevier Inc., 2011

[4] D. da Silva Avanzi, A. Foggiatto, V.A. dos Santos, F. Deschamps, E. de Freitas Rocha Louresa, A

framework for interoperability assessment in crisis management, Journal of Industrial

Information Integration, Vol. 5, pp. 26-38, 2017

[5] H. Seppänen, K. Virrantaus, Shared situational awareness and information quality in disaster

management, Safety Science, Vol. 77, pp. 112-122, 2015

[6] ISO 25964-1:2013, The international standard for thesauri and interoperability with other

vocabularies

[7] W3C, “SKOS Simple Knowledge Organisation System”, 2012. [Online]. Available:

https://www.w3.org/2004/02/skos/. (last accessed 22 August 2017)

[8] Open Knowledge Foundation, “Linked Open Vocabularies”, 2016. [Online]. Available:

http://lov.okfn.org/dataset/lov. (last accessed 22 August 2017)

[9] DECISION No 1313/2013/EU OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 17

December 2013 on a Union Civil Protection Mechanism


https://sweet.jpl.nasa.gov/

https://www.w3.org/TR/owl-time/

https://www.w3.org/2004/02/skos/

http://lov.okfn.org/dataset/lov


www.episecc.eu

Annex

I. The selected set of concepts for the PoC

The concepts prepared for semantic matching in PoC are shown in the table below. The first column

presents the EPISECC Taxonomy’s concepts listed in alphabetical order and symbol ‘X’ in the

following columns indicates that end users’ concepts are mapped to them either exactly or broadly.

Compound terms, in the first column, are presented by facets’ values separated by a comma and put

together in brackets.

EPISECC Taxonomy’s concepts: single or compound and their descriptions

PCRFVG CNVVF MRAS

Artificial structure: A structure built by humans. X X

Bus: A motor vehicle for carrying passengers. X X X

Canadair: An aircraft designed and built specifically for aerial firefighting. X X X

Chemical: Any kind of chemical substance used for neutralisation or decontamination.

X X

Civil protection: Protection of life and property in the event of a disaster. X X X

Command and control: Distribution of results of a decision-making process. X X X

Dangerous: Likely to cause harm or injury due to a disaster. X X

Dog: A dog used by first responders during a response to a critical event. X X X

Earthmoving: A machine used for moving large quantities of earth. X X X

Earthquake: Sudden break within the upper layers of the earth, sometimes breaking the surface, resulting in the vibration of the ground, which where strong enough will cause the collapse of buildings and destruction of life and property.

X X X

Evacuation of people: Movement of people away from the threat or actual occurrence of a hazard.

X X

Excavating: A machine used for excavating large quantities of earth. X X X

Extinguishing fire: An act undertaken to terminate fire. X X X

Fire: An uncontrolled burning fire. X X X



www.episecc.eu


PCRFVG CNVVF MRAS

Firefighting device: Vehicle or vessel specifically equipped for extinguishing fire.

X X X

First responder: A person whose job requires being the first on the scene of a critical event.

X X

Flood: A temporary covering by water of land not normally covered by water.

X X

Forest fire: An uncontrolled burning fire predominantly affecting forests. X X

Helicopter: A helicopter which delivers water for aerial firefighting. X X X

Industrial disaster: Danger originating from technological or industrial accidents, dangerous procedures, infrastructure failures or certain human activities.

X X X

Landslide: A movement of soil or rock controlled by gravity and the speed of the movement usually ranges between slow and rapid, but not very slow.

X X

Lifting: Machinery designed for the hoisting & lifting of materials, equipment, or people.

X X X

Maritime transport: Technological transport accidents involving maritime modes of transport.

X X

Natural phenomenon: A locus related to the natural phenomena. X X

Non-building: A system used to support a load that was not designed for continuous human residence.

X X

Nuclear explosion: Accidental release of radiation occurring in civil facilities, exceeding the internationally established safety levels.

X X

Operation execution: A management tool used for activities of the disaster relief units performed directly at the disaster site.

X X

Physical response: An organised activity to physically cope with the immediate aftermath of a disaster.

X X

Protection of critical infrastructure: An ability to assess the damage and protect critical infrastructure as an action of a response to a critical event.

X X

Providing general help: Social assistance given to the affected people until adequate care is available.

X X X

Providing supplies to first responders: Delivering requested supplies and services to first responders on a disaster area.

X X



www.episecc.eu


PCRFVG CNVVF MRAS

Pumping system: Systems designed for pumping pollutant spill, water excess during natural disasters or for other purposes.

X X X

Recovery: Act of returning into function or saving affected infrastructure, property, environment and cultural heritage after a disaster has hit.

X X X

Rescue of animals: An act of saving affected animals from danger after a disaster has hit.

X X X

Rescue of people: An act of saving affected people from danger after a disaster has hit.

X X X

Road transport: Technological transport accidents involving road modes of transport.

X X

Search and rescue: An ability to perform search for and aid to people who are in distress or imminent danger.

X X X

Securing: Securing dangerous objects or materials. X X X

Situational report: A recurring report which records and describes a situation related to the critical event.

X X

Small machinery: A small and simple tool for coping with disaster effects or intermediate consequences.

X X

Specialised vehicle: A vehicle specialised for a particular operation during a response to a critical event.

X X X

Tank: A container or storage chamber usually used for liquid or gas, immobile or mounted on the vehicle.

X X

Terrestrial: A locus situated on the ground. X X

Total affected: The total number of affected people. X X

Tracking: A dog trained to locate trapped people. X X

Vehicle: A device used for transporting people, equipment, vehicles and materials on land, to and from disaster area.

X X X

Weather data: State of the weather in a disaster area. X X

(Actually affected, property): (Object is directly influenced by a disaster. Impact on property including cultural heritage.)

X X X

(Explosion, Technology): (A sudden, loud, and violent release of energy. A disaster originates from a malfunction of a technological structure.)

X X X



www.episecc.eu


PCRFVG CNVVF MRAS

(Fire, Terrestrial): (An uncontrolled burning fire. A locus situated on the ground.)

X X

(Rescue of people, Terrestrial): (An act of saving affected people from danger after a disaster has hit. A locus situated on the ground.)

X X

(Specialised vehicle, Land): (A vehicle specialised for a particular operation during a response to a critical event. Equipment is applicable on land.)

X X

(Specialised vehicle, Land-water): (A vehicle specialised for a particular operation during a response to a critical event. Equipment is applicable on land and water.)

X X

(Specialised vehicle, off road): (A vehicle specialised for a particular operation during a response to a critical event. A vehicle is designed to move on rough terrain.)

X X

(Specialised vehicle, on road): (A vehicle specialised for a particular operation during a response to a critical event. A vehicle is designed to move on the prepared surface – a road.)

X X X

(Specialised vehicle, Water): (A vehicle specialised for a particular operation during a response to a critical event. Equipment is applicable on water.)

X X



www.episecc.eu

II. EPISECC Taxonomy

This is the second version of the EPISECC Taxonomy developed within the project. The structure is

presented by a concept/facet and its immediate sub-structure. The concepts/facets are connected

via hyperlinks. The structure begins with universe of discourse and follows by its three main facets up

to the end nodes of the structure, subsequently.

A response to a critical event: 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.

Sub-structure:

Capacity (facet): A combination of both tangible and intangible means available within an

organization that can be used in a response to a critical event.

Disaster (facet): “Disaster means any situation which has or may have a severe impact on people, the

environment, or property, including cultural heritage.” (DECISION No 1313/2013/EU OF THE

EUROPEAN PARLIAMENT AND OF THE COUNCIL of 17 December 2013 on a Union Civil Protection

Mechanism) [9]

Locus (facet): A particular position or place where something occurs or is situated.

Organisation (facet): 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.

Time (facet): Indefinite continued progress of existence and events in the past, present, and future

regarded as a whole.

Capacity (facet): A combination of both tangible and intangible means available within an


Sub-structure:

Application (facet): Media where capacity is applied.

Capability (facet): Ability to response to a disaster in relation to capacity.

Capacity type (facet): A category of a capacity having common characteristics related to mean’s

characteristics.

Application (facet): Media where capacity is applied.



www.episecc.eu

Sub-structure:

Air: Equipment is applicable in air.

Air-water: Equipment is applicable on air and water.

Land: Equipment is applicable on land.

Land-air: Equipment is applicable on land and in air.

Land-water: Equipment is applicable on land and water.

Land-water-air: Equipment is applicable on land, water and in air.

Water: Equipment is applicable on water.

Capability (facet): Ability to response to a disaster in relation to capacity.

Sub-structure:

Capable: Ability to response to a disaster in relation to capacity.

Incapable: An organization has not capability to respond to a disaster.

Partially capable: An organization has partial capability to respond to a disaster.

Capacity type (facet): A combination of both tangible and intangible means available within an


Sub-structure:

Competence: The ability, in terms of having adequate skills and knowledge, to efficiently cope with a

situation caused by a critical event.

Resource: Assets an organisation has available for the response to a critical event.

Competence: The ability, in terms of having adequate skills and knowledge, to efficiently cope with a

situation caused by a critical event.

Sub-structure:

Coordination: An ability to manage a situation in which different organisations or parts of the same

organisation work or act together in order to achieve a common objective.



www.episecc.eu

Emergency medical service: An ability to treat and transport people that may be life threatening or

injured during a response to a critical event.

Evacuation: An ability to immediately and urgently move people away from the threat or actual

occurrence of a hazard.

Firefighting: An ability to perform an action or process of extinguishing fires.

Humanitarian aid: An ability to provide material or logistical assistance for humanitarian purposes.

Protection of property: An ability to assess the damage and protect structures and objects as an

action of a response to a critical event.

Protection of cultural heritage: An ability to assess the damage and protect cultural heritage as a

action of a response to a critical event.

Protection of critical infrastructure: An ability to assess the damage and protect critical

infrastructure as an action of a response to a critical event

Search and rescue: An ability to perform search for and aid to people who are in distress or imminent

danger.

Resource: Assets an organisation has available for the response to a critical event.

Sub-structure:

Resource status (facet): The status of the resource regarding its availability for deployment.

Resource type (facet): A category of a resource having common characteristics.

Resource status (facet): The status of the resource regarding its availability for deployment.

Sub-structure:

Available: A resource is available for deployment.

Unavailable: A resource is not available for deployment.

Unavailable: A resource is not available for deployment.

Sub-structure:

Destroyed: The resource is destroyed.

In use: A resource is in use and will become available when finishes the task.



www.episecc.eu

Maintenance: A resource is under maintenance.

Reserved: A resource is reserved.

Virtual: The resource is virtual.

In use: A resource is in use and will become available when finishes the task.

Sub-structure:

Mobile: A resource is in move.

On scene: A resource is deployed on a disaster scene.

Resource type (facet): A category of a resource having common characteristics.

Sub-structure:

Animal: An animal used by first responders during a response to a critical event.

Financial: Finances and related assets an organisation has available for the response to a critical

event.

Human: Workforce an organisation has available for the response to a critical event.

Institutional: Organisational and managerial assets an organisation developed for the response to a

critical event.

Physical: A tangible assets an organisation has available for the response to a critical event.

Animal: An animal used by first responders during a response to a critical event.

Sub-structure:

Dog: A dog used by first responders during a response to a critical event.

Horse: A horse used for crowd control.

Dog: A dog used by first responders during a response to a critical event.

Sub-structure:

Cadaver: A dog trained to locate lost people or specific substances.

Tracking: A dog trained to locate trapped people.



www.episecc.eu

Human: Workforce an organisation has available for the response to a critical event.

Sub-structure:

Human resource type (facet): A category of a human resource having common characteristics related

to the service provided.

Provision (facet): A category of a human resource having common characteristics related to the

provision of a service.

Service (facet): A category of a human resource having common characteristics related to the service

type.

Human resource type (facet): A category of a human resource having common characteristics related

to the service provided.

Sub-structure:

Civil protection member: A member of a civil protection force who acts as a first responder.

Firefighter: A first responder whose primary job is to extinguish fires.

Humanitarian organisation member: A member of a humanitarian organisation who provides aid

during the response phase.

Policeman: A member of a police force who acts as a first responder.

Provision (facet): A category of a human resource having common characteristics related to the

provision of a service.

Sub-structure:

Professional: A person who provides first response service as primary occupation.

Volunteer: A person who voluntarily provides first response service.

Service (facet): A category of a human resource having common characteristics related to the service

type.

Sub-structure:

Administrative: A person who supports first responders on the scene of a critical event.



www.episecc.eu

First responder: A person whose job requires being the first on the scene of a critical event.

Institutional: Organisational and managerial assets an organisation developed for the response to a

critical event.

Sub-structure:

Communication: The mode for exchanging of information by speaking, writing, or using some other

medium.

Data set: An identifiable collection of data used by end users during the response to a critical event.

Management tool: A tool which facilitate both adequate preparedness as well as effective response

to disasters within and outside the EU Civil Protection Mechanism.

Process/Mission: Process/mission is a set of actions aiming for a certain result, executed by an

organisation during a response to a critical event.

Communication: The mode for exchanging of information by speaking, writing, or using some other

medium.

Sub-structure:

Audio and video conference: Two or more locations to communicate by simultaneous two-way video

and audio transmissions.

e-mail: A method of exchanging digital messages from an author to one or more recipients.

e-service: Online service including any processing capability available on the Internet.

Face to face: A face-to-face conversation.

Multimedia messaging: A method of exchanging images and videos between two or more mobile

phones or fixed or portable devices over a communication network.

Social Media: Internet tools that allow people to create, share, or exchange information, images or

video.

Text messaging: A method of exchanging text messages between two or more mobile phones or

fixed or portable devices over a communication network.

Voice messaging: A method of exchanging voice messages between two or more mobile phones or

fixed or portable devices over a communication network.

Wiki: Internet tool that allow people to collaboratively create and edit content of a web site or



www.episecc.eu

database.

Data set: An identifiable collection of data used by end users during the response to a critical event.

Sub-structure:

Data set content (facet): A category of a data set having common characteristics related to its origin.

Data set format (facet): Organisation of data according to certain specifications.

Data set type (facet): A category of a data set having common characteristics related to a form.

Data set use (facet): The rights or authorisation to use data.

Data set content (facet): A category of a data set having common characteristics related to its origin.

Sub-structure:

Affected people data: Data about people affected by a disaster.

Census data: An official count or survey of a population in affected area.

Cultural heritage data: Data related to the affected cultural heritage.

Damage data: Estimated damages of relevant infrastructures and/or buildings.

Early warning data: Data indicating near threat of hazard of a certain disaster.

Earth observation data: information, derived from space, airborne, land and marine sensors'

networks.

Geographical data: Spatial data related to the affected area.

Geophysical data: Data on solid earth connected to the actual disaster.

Marine data: Data on marine system connected to the actual disaster.

Medical aid data: Data on the availability of hospital resources.

Natural resources data: Data on the natural resources affected by the disaster.

Property data: Data related to the affected property.

Resource data: Data about resources of an organisation engaged in a response to a critical.

Situational report: A recurring report which records and describes a situation related to the critical

event.

Strategic infrastructure data: Data about assets which deserves special attention, priority or has a



www.episecc.eu

critical role during a response to a critical event.

Weather data: State of the weather in a disaster area.

Weather forecast: Data resulting from the analysis of the state of the weather in a disaster area with

an assessment of likely developments.

Affected people data: Data about people affected by a disaster.

Sub-structure:

Casualties: Data about people who are killed or injured during a disaster.

Homeless: The number of individuals reported needing immediate assistance for shelter.

Missing: The number of individuals reported or presumed missing.

Total affected: The total number of affected people.

Casualties: Data about people who are killed or injured during a disaster.

Sub-structure:

Injured with high priority: The number of individuals reported injured with high priority for medical

intervention.

Injured with low priority: The number of individuals reported injured with low priority for medical

intervention.

Killed: The number of individuals reported or presumed killed.

Management tool: A tool which facilitate both adequate preparedness as well as effective response

to disasters within and outside the EU Civil Protection Mechanism.

Sub-structure:

Interoperability (facet): The interoperability is the communication between the different

organisation units during a process and includes the used communication medium, the type of data,

the versioned tools, which was used to send and receive the data, and the date.

Level of application (facet): An organisational level the tool is used.

Organisational scope (facet): Scope within a tool is used.

PPDR phase (facet): A period or stage within PPDR.



www.episecc.eu

Interoperability (facet): The interoperability is the communication between the different

organisation units during a process and includes the used communication medium, the type of data,

the versioned tools, which was used to send and receive the data, and the date.

Sub-structure:

Physical interoperability: Physical communication infrastructure used to exchange data with a tool.

Semantic interoperability: Ability to exchange data using semantic structures.

Syntactical interoperability: Ability to exchange data with other PPDR management systems.

Level of application (facet): An organisational level the tool is used.

Sub-structure:

Operation execution: A tool used for activities of the disaster relief units performed directly at the

disaster site.

Operation planning and control: A tool is used for tasks dealing with unit deployment and

replenishment as well as the controlling of the different disaster relief operations running

simultaneously at the basis are situated.

Strategy and support: A tool is used for activities in the course of the disaster relief process are

monitored based on the information obtained from the levels below.

Organisational scope (facet): Scope within a tool is used.

Sub-structure:

Bilateral: Usage by two organisations or entities.

Internal: Usage by one organisation or entity.

Multilateral: Usage by multiple organisations or entities.

PPDR phase (facet): A period or stage within PPDR.

Sub-structure:

Response: A phase of immediate action of first responders in a respond to a critical event.

Response and post-response: A phase of immediate action of first responders in a respond to a



www.episecc.eu

critical event plus recovery phase.

Response and pre-response: A phase of immediate action of first responders in a respond to a critical

event plus preparedness phase.

Response, pre- and post-response: A phase of immediate action of first responders in a respond to a

critical event plus preparedness and recovery phases.

Process/Mission: Process/Mission is a set of actions aiming for a certain result, executed by an

organisation during a response to a critical event.

Sub-structure:

Process category (facet): A category of a process having common characteristics related to

specification.

Process priority (facet): A process status related to its importance.

Process status (facet): The position of the process related to its completion.

Process type (facet): A type of a process having common characteristics related to the object of a

communication.

Process category (facet): A category of a process having common characteristics related to

specification.

Sub-structure:

Non-standardised process: There are no written instructions how to perform activities during a

response to a critical event.

Standard operating procedure: Written instructions intended to document how to perform activities

during a response to a critical event.

Process priority (facet): A process status related to its importance.

Sub-structure:

High priority: The importance of a process is assessed as high.

Low priority: The importance of a process is assessed as low.

Medium priority: The importance of a process is assessed as medium.



www.episecc.eu

Process status (facet): The position of the process related to its completion.

Sub-structure:

Finished: A process is terminated after all its activities have been done.

In progress: A process is in execution.

Planned: A process will be started in the future.

Stopped: A process has been aborted either intentionally or unintentionally without finishing all its

activities.

Process type (facet): A type of a process having common characteristics related to the object of a

communication.

Sub-structure:

Command and control: Distribution of results of a decision-making process.

Interaction with people: Mutual interaction between organisations and affected people.

Interoperability actions: Exchanging information between different organisational units using

communication media and tools.

Physical response: An organised activity to physically cope with the immediate aftermath of a

disaster.

Resources management: Allocating and using resources during a response to a critical event.

Command and control: Distribution of results of a decision-making process.

Sub-structure:

Coordinating: Acting in a way in which different organisations or parts of the same organisation work

or act together.

Protecting disaster area: Controlling external influences to a disaster area.

Setting up a staging area: Organising an area where first responders, vehicles, equipment or material

are assembled.

Traffic regulation and control: Managing the movement of vehicles on or near disaster area.



www.episecc.eu

Interaction with people: Mutual interaction between organisations and affected people.

Sub-structure:

Communication with people: Mutual exchange of critical information between organisations and

people.


Providing general help: Social assistance given to the affected people until adequate care is available.

Providing medical aid: Help given to the injured people until full medical aid is available.

Transporting injured people: Moving injured people from a disaster are to hospitals or adequate

institution.


Sub-structure:

Evacuation of immobile persons: A person is incapable of moving on its own.

Evacuation of mobile persons: A person is incapable of moving on its own.

Interoperability actions: Exchanging information between different organisational units using

communication media and tools.

Sub-structure:

Communication with other organisations: A process exchanges information with other organisations.

Communication with other organisations and internally: A process exchanges information with both

other organisations and internal organisational units.

Internal communication: A process exchanges information within single organisation.

Re-establishment: Re-establishment of the communication infrastructure.

Physical response: An organised activity to physically cope with the immediate aftermath of a

disaster.

Sub-structure:

Decontamination: Cleaning equipment, infrastructure, terrain, humans or area to remove



www.episecc.eu

contaminants including CBRN.

Extinguishing fire: An act undertaken to terminate fire.

Recovery: Act of returning into function or saving affected infrastructure, property, environment and

cultural heritage after a disaster has hit.

Rescue of animals: An act of saving affected animals from danger after a disaster has hit.

Rescue of people: An act of saving affected people from danger after a disaster has hit.

Search for animals: An act of finding affected animals after a disaster has hit.

Search for people: An act of finding affected people after a disaster has hit.

Securing: Securing dangerous objects or materials.

Resources management: Allocating and using resources during a response to a critical event.

Sub-structure:

Providing resources to a disaster area: Delivering resources and services to a disaster area.

Providing supplies to first responders: Delivering requested supplies and services to first responders

on a disaster area.

Providing supplies to people: Delivering requested supplies and services to people affected by a

disaster.

Physical: A tangible asset an organisation has available for the response to a critical event.

Sub-structure:

Equipment: Supplies or tools used by an organisation during a response to a critical event.

Infrastructure: Physical and organizational structures, systems and facilities needed for the operation

during the response to a critical event.

Equipment: Supplies or tools used by an organisation during a response to a critical event.

Sub-structure:

Auxiliary equipment: Auxiliary supplies or tools used by an organisation during a response to a critical

event.



www.episecc.eu

Communication device: An end node of a technical system an organisation uses for sharing

information with other organisations involved in a response to a critical event.

Machinery: A technical system for coping with disaster effects or intermediate consequences.

Material: A substance used to deal with disaster effects or intermediate consequences.

Transportation: A device used for transporting people, equipment, vehicles and materials to and

from disaster area.

Auxiliary equipment: Auxiliary supplies or tools used by an organisation during a response to a critical

event.

Sub-structure:

Humanitarian equipment: Supplies or tools used by an organisation during a humanitarian disaster.

Technical: A supporting structure providing facility which helps first responders in their operations

during response to a critical event.

Humanitarian Equipment: Supplies or tools used by an organisation during a humanitarian disaster.

Sub-structure:

Sanitation: Substances and/or tools for water treatment and sanitation support for affected people

during a disaster.

Shelter: Shelter for affected people after a disaster strikes, build up within hours and for temporary

accommodation.

Hygiene: Hygiene material for affected people.

Field kitchen: Structured apparatuses for providing food & nutrition to affected people during a

disaster.

Cloths: Clothes for affected people after a disaster strikes for temporary accommodation.

Communication device: An end node of a technical system an organisation uses for sharing information with other organisations involved in a response to a critical event.

Sub-structure:

Computer: An electronic device which receives information (data) in a particular form and of

performing a set of procedural instructions (program) to produce a result in the form of information



www.episecc.eu

or signals.

Fax: A telephonic transmission of scanned material to a telephone number connected to a printer or

other output device.

Landline phone: A phone that uses a metal wire or fibre optic telephone line for transmission.

Mobile phone: Mobile phone is a telephone that can make and receive calls by connecting to carrier

units while the user is moving within a telephone service area.

Mobile radio: A device based on radio frequencies, and where the path of communications is

movable on either end.

Pager system: Simple personal telecommunications device for short messages.

Mobile phone: Mobile phone is a telephone that can make and receive calls by connecting to carrier

units while the user is moving within a telephone service area.

Sub-structure:

Cell phone: A mobile phone that connects to terrestrial cells.

Satellite phone: A mobile phone that connects to orbiting satellites.

Machinery: A technical system for coping with disaster effects or intermediate consequences.

Sub-structure:

Anti-pollution: A machine used to minimise impact of polluters.

Compressor: A mobile air compressor station for maintenance and service operations, and for the

filling of inflatable equipment.

Cutting: A machine used to cut, weaken, shear or break a material.

Demining: A machine used for humanitarian minesweeping and/or mine clearance.

Earthmoving: A machine used for moving large quantities of earth.

Excavating: A machine used for excavating large quantities of earth.

Fire-fighting: A machine used to cope with or extinguish a fire.

Life-sustaining: A machine used to mechanically sustains, restores, or supplants a vital bodily

functions.

Lifting: Machinery designed for the hoisting & lifting of materials, equipment, or people.



www.episecc.eu

Lightning: A machine used to illuminate disaster/emergency area.

Pumping system: Systems designed for pumping pollutant spill, and water excess during natural

disasters.

Respiratory: Equipment which supports/creates normal breathing conditions during a disaster.

Small machinery: A small and simple tool for coping with disaster effects or intermediate

consequences.

Tank: A container or storage chamber usually used for liquid or gas, immobile or mounted on the

vehicle.

Fire-fighting: A machine used to cope with or extinguish a fire.

Sub-structure:

Air-tractor: An aircraft specialised for firefighting mission.

Canadair: An aircraft designed and built specifically for aerial firefighting.

Firefighting device: Vehicle or vessel specifically equipped for extinguishing

fire.

Helicopter: A helicopter which delivers water for aerial firefighting.

Ventilation: Allows the ventilation and cooling of large structures.

Material: A substance used to deal with disaster effects or intermediate consequences.

Sub-structure:

Chemical: Any kind of chemical substance used for neutralisation or decontamination.

Construction materials: Any kind of material used for building auxiliary or repairing existing

structures during a response to a critical event.

Food: Any nutritional substance consumed by either people or first responders during a response to

a critical event.

Medical: Any kind of medical material used for relief or saving lives during the disaster.

Oil: Any kind of oil used for running the equipment.

Water as material: Water needed during response phase either as drinking or technical.



www.episecc.eu

Transportation: A device used for transporting people, equipment, vehicles and materials to and

from disaster area.

Sub-structure:

Air transport: A device used for transporting people, equipment, vehicles and materials in air, to and

from disaster area.

Vehicle: A device used for transporting people, equipment, vehicles and materials on land, to and

from disaster area.

Vessel: A device used for transporting people, equipment, vehicles and materials on sea, to and from

disaster area.

Vehicle: A device used for transporting people, equipment, vehicles and materials on land, to and

from disaster area.

Sub-structure:

Moving capability (facet): The way a vehicle is designed to move on.

Vehicle type (facet): A category of a vehicle having common characteristics related to its purpose.

Moving capability (facet): The way a vehicle is designed to move on.

Sub-structure:

By cable: A vehicle is designed to move on railway.

Off road: A vehicle is designed to move on rough terrain.

On and off the road: A vehicle is designed to move on both the prepared surface and rough terrain.

On rails: A vehicle is designed to move on railway.

On road: A vehicle is designed to move on the prepared surface – a road.

On road and rails: A vehicle is designed to move on both prepared surface and railway.

Vehicle type (facet): A category of a vehicle having common characteristics related to its purpose.

Sub-structure:

Bus: A motor vehicle for carrying passengers.



www.episecc.eu

Specialised vehicle: A vehicle specialised for a particular operation during a response to a critical

event.

Infrastructure: Physical and organizational structures, systems and facilities needed for the operation

during the response to a critical event.

Sub-structure:

Coverage (facet): Coverage of the infrastructure.

Infrastructure type (facet): A category of a infrastructure used during a disaster having common

characteristics related to its function.

Coverage (facet): Coverage of the infrastructure.

Sub-structure:

Good: Coverage of the infrastructure is good.

None: Infrastructure does not exist.

Poor: Coverage of the infrastructures is poor.

Infrastructure type (facet): A category of a infrastructure used during a disaster having common

characteristics related to its function.

Sub-structure:

Communication network: A technical system for sharing information with other entities during a


Evacuation spot: A structure or zone where people are gathered or are transported to from the

disaster area.

Public utilities: A set of services provided by public or private companies consumed by the public like

electricity, natural gas, water, sewage and broadband internet.

Transportation infrastructure: Infrastructure which can be used for transportation of people and

goods in any media during a disaster.

Communication network: A technical system for sharing information with other entities during a




www.episecc.eu

Sub-structure:

CDMA2000: A family of 3G mobile technology standards for sending voice, data, and signaling data

between mobile phones and cell sites.

Dedicated IP: A dedicated IP (Internet Protocol) is a unique Internet address dedicated exclusively to

a single hosting account.

GSM: Mobile telephone network used for voice and/or data transmission.

IS-95: CDMA-based digital cellular technology.

LTE: Long-Term Evolution, commonly marketed as 4G LTE is a standard for wireless communication

of high-speed data for mobile phones and data terminals.

Public IP: An IP (Internet Protocol) address that is assigned to a computing device to allow direct

access over the Internet.

SAT IP: A protocol and IP-based architecture for receiving and distributing satellite signals.

TETRA: A professional mobile radio and two-way transceiver specification.

TETRAPOL: A digital professional mobile radio standard, analogue radio, a transmission method of

conveying voice, data, image, signal or video information using a continuous signal.

UTMS: 3rd generation of the public mobile telephone network used for voice and/or data

transmission.

Disaster (facet): “Disaster means any situation which has or may have a severe impact on people, the

environment, or property, including cultural heritage.” (DECISION No 1313/2013/EU OF THE

EUROPEAN PARLIAMENT AND OF THE COUNCIL of 17 December 2013 on a Union Civil Protection

Mechanism) [9]

Sub-structure:

Appearance (facet): A way disaster performs.

Cause (facet): A person or thing that gives rise to a disaster.

Complexity (facet): A combination of several impacts or disaster types.

Disaster object (facet): A category of a disaster having common characteristics related to the object

of an impact.

Disaster progress (facet): A current status of a disaster related to the impact and its progress in time.

Disaster status (facet): Describes the current status of the disaster related to the first responders



www.episecc.eu

capacity or object of the impact.

Disaster type (facet): A category of a disaster having common characteristics related to behaviour.

Impact (facet): The extent of severity or consequences a disaster poses on people, the environment,

or property, including cultural heritage.

Scope (facet): The subject matter a disaster deals with or to which it is relevant.

Spatial scope (facet): A geographical area a disaster is relevant to.

Appearance (facet): A way disaster of performs.

Sub-structure:

Slow: A slow onset of a disaster.

Sudden: A sudden onset of a disaster.

Cause (facet): A person or thing that gives rise to a disaster.

Sub-structure:

Humans: A disaster originates from the effects of human activities, either deliberately or accidentally.

Nature: A disaster originates from forces of nature.

Technology: A disaster originates from a malfunction of a technological structure.

Humans: A disaster originates from the effects of human activities, either deliberately or accidentally.

Sub-structure:

Direct human influence: Human activities directly cause a disaster.

Indirect human influence: Human activities produce circumstances which cause a disaster.

Complexity (facet): A combination of several impacts or disaster types.

Sub-structure:

Cascading: A combination of impacts or disaster types shortly following each other.



www.episecc.eu

Multiple: A combination of impacts or disaster types occurring at the same time.

Simple: Only one impact or disaster type occurs.

Disaster object (facet): A category of a disaster having common characteristics related to the object

of an impact.

Sub-structure:

Circumstance (facet): A situation affecting the way in which a disaster impacts.

Object type (facet): A group of objects affected by disaster's impact.

Circumstance (facet): A situation affecting the way in which a disaster impacts.

Sub-structure:

Actually affected: Object is directly influenced by a disaster.

Potentially affected: There is a significant risk that an object will be influenced by a disaster in a

critical time period.

Object type (facet): A group of objects affected by disaster's impact.

Sub-structure:

Environment: A disaster which includes impact on nature/environment.

Environment and property: A disaster which impacts nature/environment and property including

cultural heritage.

People: A disaster which predominantly impacts people in terms of health, safety or well being of a

community.

People and environment: A disaster which impacts people in terms of health, safety or well being of

a community and nature/environment.

People and property: A disaster which impacts people in terms of health, safety or well being of a

community and property.

People, environment and property: A disaster which impacts people in terms of health, safety or well

being of a community, nature/environment and property including cultural heritage.

Property: A disaster which includes impact on property including cultural heritage.



www.episecc.eu

Disaster progress (facet): A current status of a disaster related to the impact and its progress in time.

Sub-structure:

Disaster in progress: A disaster is in progress, meaning the impact does not change or it increases.

Disaster not started: A disaster has not started, meaning the impact is zero.

Disaster stopped: A disaster is over, meaning the impact is gone or it diminishes.

Disaster status (facet): Describes the current status of the disaster related to the first responders

capacity or object of the impact.

Sub-structure:

Not under control: The first responders either need more resources or humans, nature/environment

and property including cultural heritage are endangered.

Under control: The first responders either do not need more resources or people,

nature/environment and property including cultural heritage are not endangered.

Disaster type (facet): A category of a disaster having common characteristics related to behaviour.

Sub-structure:

Avalanche: A quantity of snow or ice that slides down a mountainside under the force of gravity.

Cold wave: A prolonged period of excessively cold weather and the sudden invasion of very cold air

over a large area.

Debris flow: Downhill sliding or falling movement of soil and rock.

Earthquake: Sudden break within the upper layers of the earth, sometimes breaking the surface,

resulting in the vibration of the ground, which where strong enough will cause the collapse of

buildings and destruction of life and property.

Fire: An uncontrolled burning fire.


Heat wave: A prolonged period of excessively hot and sometimes also humid weather relative to

normal climate patterns of a certain region.

Industrial disaster: Danger originating from technological or industrial accidents, dangerous



www.episecc.eu

procedures, infrastructure failures or certain human activities.

Landslide: A movement of soil or rock controlled by gravity and the speed of the movement usually

ranges between slow and rapid, but not very slow.

Migrant crisis: A huge number of people who moves from one place to another in order to find work

or better living conditions.

Refugee crisis: A huge number of people fleeing from a danger or a problem.

Rockfall: Quantities of rock or stone falling freely from a cliff face.

Storm: Any disturbed state of an environment or astronomical body's atmosphere especially

affecting its surface, and strongly implying severe weather.

Storm surge: Rise of the water level in the sea, an estuary or lake as result of strong wind driving the

seawater towards the coast.

Subsidence: A motion of the Earth's surface as it shifts downward relative to sea level.

Transport accidents: Technological transport accidents involving mechanised modes of transport.

Tsunami: A series of waves caused by a rapid displacement of a body of water.

Volcanic eruption: A discharge of lava and gas from a volcanic vent.

Fire: An uncontrolled burning fire.

Sub-structure:

Bush fire: An uncontrolled burning fire predominantly affecting bush.

Forest fire: An uncontrolled burning fire predominantly affecting forests.

Grassland fire: An uncontrolled burning fire predominantly affecting grassland.

Urban fire: An uncontrolled burning fire predominantly affecting infrastructure and buildings.


Sub-structure:

Flash flood: Sudden and extreme volume of water that flow rapidly and cause inundation.

Floods from the sea in coastal areas: Occurs when normally dry, low-lying land is flooded by sea

water.

Glacial lake outburst flood: Occurs when a lake - dammed by a glacier or a terminal moraine - fails.



www.episecc.eu

River flood: A temporary covering by river water of land not normally covered by water.

Urban flood: Inundation of land or property in a built environment, particularly in more densely

populated areas.

Industrial disaster: Danger originating from technological or industrial accidents, dangerous

procedures, infrastructure failures or certain human activities.

Sub-structure:

Accident release: Occurring during the production, transportation or handling of hazardous chemical

substances.

Acid rain: A washout of an excessive concentration of acidic compounds in the atmosphere, resulting

from chemical pollutants such as sulphur and nitrogen compounds.

Chemical explosion: Violent destruction caused by explosion of combustible material, nearly always

of chemical origin.

Explosion: A sudden, loud, and violent release of energy.

Mine explosion: Occurs when natural gas or coal dust reacts with the air.

Nuclear explosion: Accidental release of radiation occurring in civil facilities, exceeding the

internationally established safety levels.

Pollution: Degradation of one or more aspects in the environment by noxious industrial, chemical or

biological wastes, from debris or man-made products and from mismanagement of natural and

environmental resources.

Storm: Any disturbed state of an environment or astronomical body's atmosphere especially

affecting its surface, and strongly implying severe weather.

Sub-structure:

Convective storm: A result of convection and condensation in the lower atmosphere and the

accompanying formation of a cumulonimbus cloud.

Local storm: Strong winds caused by regional atmospheric phenomena which are typical for a certain

area.

Snowstorm: A storm, usually in the winter season, where large amounts of snow fall.

Tropical storm: A large scale closed circulation system in the atmosphere which combines low

pressure and strong winds that rotate counter clockwise in the northern hemisphere and clockwise in



www.episecc.eu

the southern hemisphere.

Winter storm: An extra-tropical cyclone, a synoptic scale low pressure system that occurs in the

middle latitudes of the Earth and is connected to fronts and horizontal gradients in temperature and

dew point.

Transport accidents: Technological transport accidents involving mechanised modes of transport.

Sub-structure:

Air transport: Technological transport accidents involving air modes of transport.

Maritime transport: Technological transport accidents involving maritime modes of transport.

Rail transport: Technological transport accidents involving rail modes of transport.

River and lake transport: Technological transport accidents involving river and lake modes of

transport.

Road transport: Technological transport accidents involving road modes of transport.

Impact (facet): The extent of severity or consequences a disaster poses on people, the environment,

or property, including cultural heritage.

Sub-structure:

Extreme impact: An extreme impact calculated in accordance with disaster impact scale or

assessment procedure.

High impact: A high impact calculated in accordance with disaster impact scale or assessment

procedure.

Low impact: A low impact calculated in accordance with disaster impact scale or assessment

procedure.

Medium impact: A medium impact calculated in accordance with disaster impact scale or assessment

procedure.

Scope (facet): The subject matter a disaster deals with or to which it is relevant.

Sub-structure:

Economic and social: Scope related to the impact to both the society wellbeing and the damage



www.episecc.eu

caused by a disaster.

Economic scope: Scope related to the damage caused by a disaster.

Social scope: Scope related to the impact to the society wellbeing.

Spatial scope (facet): A geographical area a disaster is relevant to.

Sub-structure:

Cross-border: A disaster occurs in two or more countries sharing borders.

Global: A disaster occurs globally involving more countries.

One country: A disaster occurs within one country.

Locus (facet): A particular position or place where something occurs or is situated.

Sub-structure:

Character (facet): The possibility of suffering harm or injury due to a disaster.

Locus Type (facet): A category of a locus having common characteristics.

Population density (facet): Number of persons per unit area or unit volume.

Position (facet): The way in which someone or something is related to a particular place.

Shape (facet): A shape of where someone or something is located or has been put.

Character (facet): The possibility of suffering harm or injury due to a disaster.

Sub-structure:

Dangerous: Likely to cause harm or injury due to a disaster.

Non-dangerous: Unlikely to cause harm or injury due to a disaster.

Locus Type (facet): A category of a locus having common characteristics.

Sub-structure:

Artificial structure: A structure built by humans.



www.episecc.eu

Natural phenomenon: A locus related to the natural phenomena.

Artificial structure: A structure built by humans.

Sub-structure:

Areal: A locus situated in the air.

Terrestrial: A locus situated on or under the ground.

Water related: A locus situated on or under the water.

Natural phenomenon: A locus related to the natural phenomena.

Sub-structure:

Non-building: A system used to support a load that was not designed for continuous human

residence.

Private building: A building owned by non-governmental legal entities.

Public building: A building owned by a state entity.

Population Density (facet): Number of persons per unit area or unit volume.

Sub-structure:

High density: Estimated number of persons per unit area or unit volume is high.

Low density: Estimated number of persons per unit area or unit volume is low.

Unsettled: There are no persons in a particular locus.

Position (facet): The way in which someone or something is related to a particular place.

Sub-structure:

Inside: The inner side of two- or three-dimensional place.

Outside: The external side of two- or three-dimensional place.



www.episecc.eu

Shape (facet): A shape of where someone or something is located or has been put.

Sub-structure:

Area: A two-dimensional shape, in the plane or on the surface of a three-dimensional object.

Line: An one-dimensional shape, either straight or curved, connecting all points having a specified

common property.

Point: A shape having position usually as coordinates but not spatial extent.

Space: A three-dimensional shape.

Organisation (facet): 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.

Sub-structure:

Business model (facet): A way an organisation uses and exchanges information with other

organisations or data providers.

Operational scope (facet): Scope related to the decision-making level.

Organisation type (facet): Organisations having common characteristics related to the way they

founded.

Spatial scope (facet): Spatial scope of organisation's activities and/or presence.

Specialisation (facet): Organisations having common characteristics related to the specialisation to

cope with a disaster.

Business model (facet): A way an organisation use and exchange information with other

organisations or data providers.

Sub-structure:

Information from service provider: An organisation gets information from service provider.

Information from service provider and generated in organisation: An organisation gets information

from service provider and generates information in the organisation.

Information generated in organisation: Information are being generated in the organisation.



www.episecc.eu

Operational scope (facet): Scope related to the decision-making level.

Sub-structure:

Operational: An organisation manages activities at operational level.

Strategic: An organisation manages activities at strategic level.

Strategic-tactical: An organisation manages activities at strategic and tactical level.

Strategic-tactical-operational: An organisation manages activities at strategic, tactical and

operational level.

Tactical: An organisation manages activities at tactical level.

Tactical-operational: An organisation manages activities at tactical and operational level.

Organisation type (facet): Organisations having common characteristics related to the way they

founded.

Sub-structure:

Governmental: An organisation that is a part of a government.

Non-governmental: An organisation that is neither a part of a government nor a conventional for-

profit business.

Private: An organisation performing a conventional for-profit business.

Spatial scope (facet): Spatial scope of organisation's activities and/or presence.

Sub-structure:

European: An organisation with the European scope or presence.

International: An organisation with an international scope or presence.

Local: An organisation with a local scope or presence.

National: An organisation with an international scope or presence.

Regional: An organisation with an international scope or presence.

Specialisation (facet): Organisations having common characteristics related to the specialisation to

cope with a disaster.



www.episecc.eu

Sub-structure:

Civil protection: Protection of life and property in the event of a disaster.

Emergency medical assistance: Treatment and transport of people that may be life threatening or

injured during a response to a critical event.

Humanitarian assistance: Material or logistical assistance provided for humanitarian purposes.

Recovery of cultural heritage: Protection of cultural heritage in the event of a disaster.

Search and rescue operations: Search for and provision of aid to people who are in distress or

imminent danger.

Time (facet): Indefinite continued progress of existence and events in the past, present, and future

regarded as a whole.

Sub-structure:

Instant: It has zero length, where the beginning and end are the same.

Interval: Time with extent, having length, where the beginning and end are not the same.


www.episecc.eu

III. EPISECC Ontology model

This is the second version of the EPISECC Ontology model developed within the project. The model is

written in RDF/XML syntax.

<?xml version="1.0"?>

<!DOCTYPE rdf:RDF [

<!ENTITY terms "http://purl.org/dc/terms/" >

<!ENTITY owl "http://www.w3.org/2002/07/owl#" >

<!ENTITY dc "http://purl.org/dc/elements/1.1/" >

<!ENTITY xsd "http://www.w3.org/2001/XMLSchema#" >

<!ENTITY skos "http://www.w3.org/2004/02/skos/core#" >

<!ENTITY rdfs "http://www.w3.org/2000/01/rdf-schema#" >

<!ENTITY webprotege "http://protege.stanford.edu/webprotege/" >

<!ENTITY rdf "http://www.w3.org/1999/02/22-rdf-syntax-ns#" >

]>

<rdf:RDF xmlns="http://www.episecc.eu#"

xml:base="http://www.episecc.eu"

xmlns:dc="http://purl.org/dc/elements/1.1/"

xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"

xmlns:webprotege="http://protege.stanford.edu/webprotege/"

xmlns:terms="http://purl.org/dc/terms/"

xmlns:owl="http://www.w3.org/2002/07/owl#"

xmlns:xsd="http://www.w3.org/2001/XMLSchema#"

xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

xmlns:skos="http://www.w3.org/2004/02/skos/core#">

<owl:Ontology rdf:about="http://www.episecc.eu/sem_rep">

<rdfs:comment rdf:datatype="&xsd;string">EPISECC is co-financed from the EU funds under grant agreement no. 607078 within the Seventh Framework Programme.</rdfs:comment>

<dc:creator rdf:datatype="&xsd;string">EPISECC project consortium</dc:creator>

</owl:Ontology>

www.episecc.eu



<rdf:Description rdf:about="&dc;contributor">

<rdfs:label xml:lang="en">Contributor</rdfs:label>

<terms:issued rdf:datatype="&xsd;date">1999-07-02</terms:issued>

<terms:modified rdf:datatype="&xsd;date">2008-01-14</terms:modified>

<skos:note xml:lang="en">A second property with the same name as this property has been declared in the dcterms: namespace (http://purl.org/dc/terms/). See the Introduction to the document "DCMI Metadata Terms" (http://dublincore.org/documents/dcmi-terms/) for an explanation.</skos:note>

<rdfs:comment xml:lang="en">An entity responsible for making contributions to the resource.</rdfs:comment>

<terms:description xml:lang="en">Examples of a Contributor include a person, an organization, or a service. Typically, the name of a Contributor should be used to indicate the entity.</terms:description>

<terms:hasVersion rdf:resource="http://dublincore.org/usage/terms/history/#contributor-006"/>

<rdfs:isDefinedBy rdf:resource="http://purl.org/dc/elements/1.1/"/>

</rdf:Description>



<rdf:Description rdf:about="&dc;creator">

<rdfs:label xml:lang="en">Creator</rdfs:label>




<rdfs:comment xml:lang="en">An entity primarily responsible for making the resource.</rdfs:comment>

<terms:description xml:lang="en">Examples of a Creator include a person, an organization, or a service. Typically, the name of a Creator should be used to indicate the entity.</terms:description>

<terms:hasVersion rdf:resource="http://dublincore.org/usage/terms/history/#creator-006"/>


</rdf:Description>



<rdf:Description rdf:about="&dc;date">

<rdfs:label xml:lang="en">Date</rdfs:label>



<rdfs:comment xml:lang="en">A point or period of time associated with an event in the lifecycle of the resource.</rdfs:comment>


<terms:description xml:lang="en">Date may be used to express temporal information at any level of

www.episecc.eu

granularity. Recommended best practice is to use an encoding scheme, such as the W3CDTF profile of ISO 8601 [W3CDTF].</terms:description>

<terms:hasVersion rdf:resource="http://dublincore.org/usage/terms/history/#date-006"/>


</rdf:Description>



<rdf:Description rdf:about="&dc;description">

<rdfs:label xml:lang="en">Description</rdfs:label>




<rdfs:comment xml:lang="en">An account of the resource.</rdfs:comment>

<terms:description xml:lang="en">Description may include but is not limited to: an abstract, a table of contents, a graphical representation, or a free-text account of the resource.</terms:description>

<terms:hasVersion rdf:resource="http://dublincore.org/usage/terms/history/#description-006"/>


</rdf:Description>



<owl:AnnotationProperty rdf:about="&terms;description"/>



<owl:AnnotationProperty rdf:about="&terms;hasVersion"/>



<owl:AnnotationProperty rdf:about="&terms;issued"/>



<owl:AnnotationProperty rdf:about="&terms;modified"/>

www.episecc.eu



<owl:AnnotationProperty rdf:about="&terms;publisher"/>



<owl:AnnotationProperty rdf:about="&terms;title"/>



<owl:AnnotationProperty rdf:about="&skos;altLabel">

<rdfs:label xml:lang="en">alternative label</rdfs:label>

<skos:example xml:lang="en">Acronyms, abbreviations, spelling variants, and irregular plural/singular forms may be included among the alternative labels for a concept. Mis-spelled terms are normally included as hidden labels (see skos:hiddenLabel).</skos:example>

<skos:definition xml:lang="en">An alternative lexical label for a resource.</skos:definition>

<rdfs:comment xml:lang="en">The range of skos:altLabel is the class of RDF plain literals.</rdfs:comment>

<rdfs:comment xml:lang="en">skos:prefLabel, skos:altLabel and skos:hiddenLabel are pairwise disjoint properties.</rdfs:comment>

<rdfs:subPropertyOf rdf:resource="&rdfs;label"/>

<rdfs:isDefinedBy rdf:resource="http://www.w3.org/2004/02/skos/core"/>

</owl:AnnotationProperty>



<owl:AnnotationProperty rdf:about="&skos;changeNote">

<rdfs:label xml:lang="en">change note</rdfs:label>

<skos:definition xml:lang="en">A note about a modification to a concept.</skos:definition>


<rdfs:subPropertyOf rdf:resource="&skos;note"/>




<owl:AnnotationProperty rdf:about="&skos;definition">

<rdfs:label xml:lang="en">definition</rdfs:label>

<skos:definition xml:lang="en">A statement or formal explanation of the meaning of a concept.</skos:definition>

www.episecc.eu



<owl:AnnotationProperty rdf:about="&skos;editorialNote">

<rdfs:label xml:lang="en">editorial note</rdfs:label>

<skos:definition xml:lang="en">A note for an editor, translator or maintainer of the vocabulary.</skos:definition>






<owl:AnnotationProperty rdf:about="&skos;example">

<rdfs:label xml:lang="en">example</rdfs:label>

<skos:definition xml:lang="en">An example of the use of a concept.</skos:definition>






<owl:AnnotationProperty rdf:about="&skos;hiddenLabel">

<rdfs:label xml:lang="en">hidden label</rdfs:label>

<skos:definition xml:lang="en">A lexical label for a resource that should be hidden when generating visual displays of the resource, but should still be accessible to free text search operations.</skos:definition>

<rdfs:comment xml:lang="en">The range of skos:hiddenLabel is the class of RDF plain literals.</rdfs:comment>

<rdfs:comment xml:lang="en">skos:prefLabel, skos:altLabel and skos:hiddenLabel are pairwise disjoint properties.</rdfs:comment>






<owl:AnnotationProperty rdf:about="&skos;historyNote">

<rdfs:label xml:lang="en">history note</rdfs:label>

<skos:definition xml:lang="en">A note about the past state/use/meaning of a concept.</skos:definition>

www.episecc.eu




<owl:AnnotationProperty rdf:about="&skos;note">

<rdfs:label xml:lang="en">note</rdfs:label>

<skos:definition xml:lang="en">A general note, for any purpose.</skos:definition>

<skos:scopeNote xml:lang="en">This property may be used directly, or as a super-property for more specific note types.</skos:scopeNote>





<owl:AnnotationProperty rdf:about="&skos;prefLabel">

<rdfs:label xml:lang="en">preferred label</rdfs:label>

<rdfs:comment xml:lang="en">A resource has no more than one value of skos:prefLabel per language tag, and no more than one value of skos:prefLabel without language tag.</rdfs:comment>

<skos:definition xml:lang="en">The preferred lexical label for a resource, in a given language.</skos:definition>

<rdfs:comment xml:lang="en">The range of skos:prefLabel is the class of RDF plain literals.</rdfs:comment>

<rdfs:comment xml:lang="en">skos:prefLabel, skos:altLabel and skos:hiddenLabel are pairwise

disjoint properties.</rdfs:comment>






<owl:AnnotationProperty rdf:about="&skos;scopeNote">

<rdfs:label xml:lang="en">scope note</rdfs:label>

<skos:definition xml:lang="en">A note that helps to clarify the meaning and/or the use of a concept.</skos:definition>




<!--

///////////////////////////////////////////////////////////////////////////////////////

//

// Datatypes

www.episecc.eu

//

///////////////////////////////////////////////////////////////////////////////////////

-->



<rdfs:Datatype rdf:about="http://www.opengis.net/ont/geosparql#gmlLiteral">

<rdfs:label xml:lang="en">GML Literal</rdfs:label>

<dc:date rdf:datatype="&xsd;date">2011-06-16</dc:date>

<skos:definition xml:lang="en">

A GML serialization of a geometry object.

</skos:definition>

<dc:description xml:lang="en">


</dc:description>

<skos:prefLabel xml:lang="en">GML Literal</skos:prefLabel>

<dc:contributor>Matthew Perry</dc:contributor>

<dc:creator>OGC GeoSPARQL 1.0 Standard Working Group</dc:creator>

<rdfs:comment xml:lang="en">


</rdfs:comment>

<rdfs:isDefinedBy rdf:resource="http://www.opengis.net/ont/geosparql"/>

<rdfs:isDefinedBy rdf:resource="http://www.opengis.net/spec/geosparql/1.0"/>

</rdfs:Datatype>



<rdfs:Datatype rdf:about="http://www.opengis.net/ont/geosparql#wktLiteral">

<rdfs:label xml:lang="en">Well-known Text Literal</rdfs:label>





A Well-known Text serialization of a geometry object.

</rdfs:comment>



</skos:definition>



</dc:description>

<skos:prefLabel xml:lang="en">Well-known Text Literal</skos:prefLabel>

www.episecc.eu

</rdfs:Datatype>



<rdfs:Datatype rdf:about="&xsd;date"/>



<rdfs:Datatype rdf:about="&xsd;gDay"/>



<rdfs:Datatype rdf:about="&xsd;gMonth"/>



<rdfs:Datatype rdf:about="&xsd;gYear"/>





<owl:ObjectProperty rdf:about="http://www.episecc.eu/sem_rep#epi00246">

<rdfs:label xml:lang="en">executes</rdfs:label>

</owl:ObjectProperty>

www.episecc.eu


<rdfs:label xml:lang="en">hasAvailable</rdfs:label>




<rdfs:label xml:lang="en">hasPriority</rdfs:label>




<rdfs:label xml:lang="en">hasStatus</rdfs:label>




<owl:ObjectProperty rdf:about="http://www.episecc.eu/sem_rep/sem_rep#epi00066">

<rdfs:label xml:lang="en">hasAffectedObject</rdfs:label>




<rdfs:label xml:lang="en">isExecutedBy</rdfs:label>

<rdfs:domain rdf:resource="http://webprotege.stanford.edu/epi00093"/>

<rdfs:range rdf:resource="http://webprotege.stanford.edu/epi00242"/>

<owl:inverseOf rdf:resource="http://www.episecc.eu/sem_rep#epi00246"/>




<rdfs:label xml:lang="en">uses</rdfs:label>


www.episecc.eu



<rdfs:label xml:lang="en">contains</rdfs:label>

<owl:inverseOf rdf:resource="http://www.episecc.eu/sem_rep/sem_rep#epi00084"/>




<rdfs:label xml:lang="en">isComposedOf</rdfs:label>




<rdfs:label xml:lang="en">isUsedBy</rdfs:label>





<rdfs:label xml:lang="en">isSpatiotemporalPartOf</rdfs:label>




<rdfs:label xml:lang="en">hasSpatiotemporalPart</rdfs:label>





<rdfs:label xml:lang="en">invokes</rdfs:label>




www.episecc.eu



<rdfs:label xml:lang="en">isInvokedBy</rdfs:label>




<owl:ObjectProperty rdf:about="http://www.opengis.net/ont/geosparql#defaultGeometry">

<rdfs:label xml:lang="en">defaultGeometry</rdfs:label>



The default geometry to be used in spatial calculations.

It is Usually the most detailed geometry.

</rdfs:comment>




</skos:definition>






</dc:description>

<skos:prefLabel xml:lang="en">defaultGeometry</skos:prefLabel>


<rdfs:domain rdf:resource="http://www.opengis.net/ont/geosparql#Feature"/>

<rdfs:range rdf:resource="http://www.opengis.net/ont/geosparql#Geometry"/>

<rdfs:subPropertyOf rdf:resource="http://www.opengis.net/ont/geosparql#hasGeometry"/>





<owl:ObjectProperty rdf:about="http://www.opengis.net/ont/geosparql#ehCoveredBy">

<rdfs:label xml:lang="en">coveredBy</rdfs:label>



Exists if the subject SpatialObject is spatially covered

by the object SpatialObject. DE-9IM: TFF*TFT**

</dc:description>

www.episecc.eu





</skos:definition>




</rdfs:comment>


<skos:prefLabel xml:lang="en">coveredBy</skos:prefLabel>


<rdfs:range rdf:resource="http://www.opengis.net/ont/geosparql#SpatialObject"/>

<rdfs:domain rdf:resource="http://www.opengis.net/ont/geosparql#SpatialObject"/>





<owl:ObjectProperty rdf:about="http://www.opengis.net/ont/geosparql#ehCovers">

<rdfs:label xml:lang="en">covers</rdfs:label>



Exists if the subject SpatialObject spatially covers the

object SpatialObject. DE-9IM: T*TFT*FF*

</dc:description>




</rdfs:comment>




</skos:definition>



<skos:prefLabel xml:lang="en">covers</skos:prefLabel>

www.episecc.eu

<owl:ObjectProperty rdf:about="http://www.opengis.net/ont/geosparql#ehEquals">

<rdfs:label xml:lang="en">equals</rdfs:label>





Exists if the subject SpatialObject spatially equals the

object SpatialObject. DE-9IM: TFFFTFFFT

</rdfs:comment>




</skos:definition>




</dc:description>

<skos:prefLabel xml:lang="en">equals</skos:prefLabel>








<owl:ObjectProperty rdf:about="http://www.opengis.net/ont/geosparql#ehInside">

<rdfs:label xml:lang="en">inside</rdfs:label>



Exists if the subject SpatialObject is spatially inside

the object SpatialObject. DE-9IM: TFF*FFT**

</skos:definition>




</rdfs:comment>




</dc:description>



<skos:prefLabel xml:lang="en">inside</skos:prefLabel>

www.episecc.eu





<owl:ObjectProperty rdf:about="http://www.opengis.net/ont/geosparql#ehMeet">

<rdfs:label xml:lang="en">meet</rdfs:label>



Exists if the subject SpatialObject spatially meets the

object SpatialObject.

DE-9IM: FT******* ^ F**T***** ^ F***T****

</rdfs:comment>






DE-9IM: FT******* ^ F**T***** ^ F***T****

</skos:definition>




DE-9IM: FT******* ^ F**T***** ^ F***T****

</dc:description>

<skos:prefLabel xml:lang="en">meet</skos:prefLabel>








<owl:ObjectProperty rdf:about="http://www.opengis.net/ont/geosparql#ehOverlap">

<rdfs:label xml:lang="en">overlap</rdfs:label>



Exists if the subject SpatialObject spatially overlaps the

object SpatialObject. DE-9IM: T*T***T**

</rdfs:comment>

www.episecc.eu

</dc:description>





</skos:definition>

<skos:prefLabel xml:lang="en">overlap</skos:prefLabel>








<owl:ObjectProperty rdf:about="http://www.opengis.net/ont/geosparql#hasGeometry">

<rdfs:label xml:lang="en">hasGeometry</rdfs:label>



A spatial representation for a given feature.

</skos:definition>



</dc:description>




</rdfs:comment>


<skos:prefLabel xml:lang="en">hasGeometry</skos:prefLabel>


<rdfs:domain rdf:resource="http://www.opengis.net/ont/geosparql#Feature"/>

<rdfs:range rdf:resource="http://www.opengis.net/ont/geosparql#Geometry"/>





<owl:ObjectProperty rdf:about="http://www.opengis.net/ont/geosparql#rcc8dc">

<rdfs:label xml:lang="en">disconnected</rdfs:label>



Exists if the subject SpatialObject is spatially disjoint

from the object SpatialObject. DE-9IM: FFTFFTTTT

</dc:description>

www.episecc.eu




</rdfs:comment>




</skos:definition>



<skos:prefLabel xml:lang="en">disconnected</skos:prefLabel>








<owl:ObjectProperty rdf:about="http://www.opengis.net/ont/geosparql#rcc8ec">

<rdfs:label xml:lang="en">externally connected</rdfs:label>




object SpatialObject. DE-9IM: FFTFTTTTT

</skos:definition>






</dc:description>




</rdfs:comment>

<skos:prefLabel xml:lang="en">externally connected</skos:prefLabel>

www.episecc.eu

<owl:ObjectProperty rdf:about="http://www.opengis.net/ont/geosparql#rcc8ntpp">

<rdfs:label xml:lang="en">non-tangential proper part</rdfs:label>




the object SpatialObject. DE-9IM: TFFTFFTTT

</dc:description>




</skos:definition>





</rdfs:comment>


<skos:prefLabel xml:lang="en">non-tangential proper part</skos:prefLabel>








<owl:ObjectProperty rdf:about="http://www.opengis.net/ont/geosparql#rcc8ntppi">

<rdfs:label xml:lang="en">non-tangential proper part inverse</rdfs:label>



Exists if the subject SpatialObject spatially contains the

object SpatialObject. DE-9IM: TTTFFTFFT

</dc:description>




</skos:definition>




</rdfs:comment>



<skos:prefLabel xml:lang="en">non-tangential proper part inverse</skos:prefLabel>

www.episecc.eu





<owl:ObjectProperty rdf:about="http://www.opengis.net/ont/geosparql#rcc8po">

<rdfs:label xml:lang="en">partially overlapping</rdfs:label>





object SpatialObject. DE-9IM: TTTTTTTTT

</skos:definition>




</dc:description>





</rdfs:comment>

<skos:prefLabel xml:lang="en">partially overlapping</skos:prefLabel>








<owl:ObjectProperty rdf:about="http://www.opengis.net/ont/geosparql#rcc8tpp">

<rdfs:label xml:lang="en">tangential proper part</rdfs:label>




by the object SpatialObject. DE-9IM: TFFTTFTTT

</skos:definition>




</rdfs:comment>

www.episecc.eu

</dc:description>



<skos:prefLabel xml:lang="en">tangential proper part</skos:prefLabel>








<owl:ObjectProperty rdf:about="http://www.opengis.net/ont/geosparql#rcc8tppi">

<rdfs:label xml:lang="en">tangential proper part inverse</rdfs:label>




object SpatialObject. DE-9IM: TTTFTTFFT

</dc:description>




</skos:definition>




</rdfs:comment>



<skos:prefLabel xml:lang="en">tangential proper part inverse</skos:prefLabel>








<owl:ObjectProperty rdf:about="http://www.opengis.net/ont/geosparql#sfContains">

<rdfs:label xml:lang="en">contains</rdfs:label>




object SpatialObject. DE-9IM: T*****FF*

</dc:description>

www.episecc.eu




</rdfs:comment>






</skos:definition>

<skos:prefLabel xml:lang="en">contains</skos:prefLabel>








<owl:ObjectProperty rdf:about="http://www.opengis.net/ont/geosparql#sfCrosses">

<rdfs:label xml:lang="en">crosses</rdfs:label>




Exists if the subject SpatialObject spatially crosses the

object SpatialObject. DE-9IM: T*T******

</rdfs:comment>




</skos:definition>




</dc:description>


<skos:prefLabel xml:lang="en">crosses</skos:prefLabel>

www.episecc.eu

<owl:ObjectProperty rdf:about="http://www.opengis.net/ont/geosparql#sfDisjoint">

<rdfs:label xml:lang="en">disjoint</rdfs:label>




from the object SpatialObject. DE-9IM: FF*FF****

</dc:description>






</skos:definition>




</rdfs:comment>

<skos:prefLabel xml:lang="en">disjoint</skos:prefLabel>








<owl:ObjectProperty rdf:about="http://www.opengis.net/ont/geosparql#sfIntersects">

<rdfs:label xml:lang="en">intersects</rdfs:label>




Exists if the subject SpatialObject is not spatially disjoint

from the object SpatialObject.

DE-9IM: T******** ^ *T******* ^ ***T***** ^ ****T****

</skos:definition>




DE-9IM: T******** ^ *T******* ^ ***T***** ^ ****T****

</rdfs:comment>





DE-9IM: T******** ^ *T******* ^ ***T***** ^ ****T****

</dc:description>

<skos:prefLabel xml:lang="en">intersects</skos:prefLabel>

www.episecc.eu








<owl:ObjectProperty rdf:about="http://www.opengis.net/ont/geosparql#sfOverlaps">

<rdfs:label xml:lang="en">overlaps</rdfs:label>







</skos:definition>




</dc:description>




</rdfs:comment>

<skos:prefLabel xml:lang="en">overlaps</skos:prefLabel>








<owl:ObjectProperty rdf:about="http://www.opengis.net/ont/geosparql#sfTouches">

<rdfs:label xml:lang="en">touches</rdfs:label>



Exists if the subject SpatialObject spatially touches the


DE-9IM: FT******* ^ F**T***** ^ F***T****

</rdfs:comment>

www.episecc.eu



DE-9IM: FT******* ^ F**T***** ^ F***T****

</dc:description>




DE-9IM: FT******* ^ F**T***** ^ F***T****

</skos:definition>

<skos:prefLabel xml:lang="en">touches</skos:prefLabel>








<owl:ObjectProperty rdf:about="http://www.opengis.net/ont/geosparql#sfWithin">

<rdfs:label xml:lang="en">within</rdfs:label>




Exists if the subject SpatialObject is spatially within the

object SpatialObject. DE-9IM: T*F**F***

</rdfs:comment>




</dc:description>





</skos:definition>

<skos:prefLabel xml:lang="en">within</skos:prefLabel>








<owl:ObjectProperty rdf:about="http://www.w3.org/2006/time#after">

www.episecc.eu

<owl:inverseOf rdf:resource="http://www.w3.org/2006/time#before"/>




<owl:ObjectProperty rdf:about="http://www.w3.org/2006/time#before">

<rdf:type rdf:resource="&owl;TransitiveProperty"/>

<rdfs:domain rdf:resource="http://www.w3.org/2006/time#TemporalEntity"/>

<rdfs:range rdf:resource="http://www.w3.org/2006/time#TemporalEntity"/>




<owl:ObjectProperty rdf:about="http://www.w3.org/2006/time#dayOfWeek">

<rdfs:domain rdf:resource="http://www.w3.org/2006/time#DateTimeDescription"/>

<rdfs:range rdf:resource="http://www.w3.org/2006/time#DayOfWeek"/>




<owl:ObjectProperty rdf:about="http://www.w3.org/2006/time#hasBeginning">

<rdfs:range rdf:resource="http://www.w3.org/2006/time#Instant"/>





<owl:ObjectProperty rdf:about="http://www.w3.org/2006/time#hasDateTimeDescription">

<rdfs:range rdf:resource="http://www.w3.org/2006/time#DateTimeDescription"/>

<rdfs:domain rdf:resource="http://www.w3.org/2006/time#DateTimeInterval"/>




<owl:ObjectProperty rdf:about="http://www.w3.org/2006/time#hasDurationDescription">

<rdfs:range rdf:resource="http://www.w3.org/2006/time#DurationDescription"/>

www.episecc.eu



<owl:ObjectProperty rdf:about="http://www.w3.org/2006/time#hasEnd">






<owl:ObjectProperty rdf:about="http://www.w3.org/2006/time#inDateTime">

<rdfs:range rdf:resource="http://www.w3.org/2006/time#DateTimeDescription"/>

<rdfs:domain rdf:resource="http://www.w3.org/2006/time#Instant"/>




<owl:ObjectProperty rdf:about="http://www.w3.org/2006/time#inside">


<rdfs:domain rdf:resource="http://www.w3.org/2006/time#Interval"/>




<owl:ObjectProperty rdf:about="http://www.w3.org/2006/time#intervalAfter">

<owl:inverseOf rdf:resource="http://www.w3.org/2006/time#intervalBefore"/>




<owl:ObjectProperty rdf:about="http://www.w3.org/2006/time#intervalBefore">

<rdfs:range rdf:resource="http://www.w3.org/2006/time#ProperInterval"/>

<rdfs:domain rdf:resource="http://www.w3.org/2006/time#ProperInterval"/>

<rdfs:subPropertyOf rdf:resource="http://www.w3.org/2006/time#before"/>

www.episecc.eu

<owl:ObjectProperty rdf:about="http://www.w3.org/2006/time#intervalContains">

<owl:inverseOf rdf:resource="http://www.w3.org/2006/time#intervalDuring"/>




<owl:ObjectProperty rdf:about="http://www.w3.org/2006/time#intervalDuring">






<owl:ObjectProperty rdf:about="http://www.w3.org/2006/time#intervalEquals">






<owl:ObjectProperty rdf:about="http://www.w3.org/2006/time#intervalFinishedBy">

<owl:inverseOf rdf:resource="http://www.w3.org/2006/time#intervalFinishes"/>




<owl:ObjectProperty rdf:about="http://www.w3.org/2006/time#intervalFinishes">






<owl:ObjectProperty rdf:about="http://www.w3.org/2006/time#intervalMeets">

www.episecc.eu



<owl:ObjectProperty rdf:about="http://www.w3.org/2006/time#intervalMetBy">

<owl:inverseOf rdf:resource="http://www.w3.org/2006/time#intervalMeets"/>




<owl:ObjectProperty rdf:about="http://www.w3.org/2006/time#intervalOverlappedBy">

<owl:inverseOf rdf:resource="http://www.w3.org/2006/time#intervalOverlaps"/>




<owl:ObjectProperty rdf:about="http://www.w3.org/2006/time#intervalOverlaps">






<owl:ObjectProperty rdf:about="http://www.w3.org/2006/time#intervalStartedBy">

<owl:inverseOf rdf:resource="http://www.w3.org/2006/time#intervalStarts"/>




<owl:ObjectProperty rdf:about="http://www.w3.org/2006/time#intervalStarts">






<owl:ObjectProperty rdf:about="http://www.w3.org/2006/time#timeZone">


<rdfs:range rdf:resource="http://www.w3.org/2006/timezone#TimeZone"/>

www.episecc.eu



<owl:ObjectProperty rdf:about="http://www.w3.org/2006/time#unitType">


<rdfs:range rdf:resource="http://www.w3.org/2006/time#TemporalUnit"/>





<owl:DatatypeProperty rdf:about="http://www.episecc.eu/sem_rep#epi00256">

<rdfs:label xml:lang="en">hasSize</rdfs:label>

</owl:DatatypeProperty>



<rdfs:label xml:lang="en">hasNumber</rdfs:label>




<rdfs:label xml:lang="en">hasValue</rdfs:label>


www.episecc.eu

<owl:DatatypeProperty rdf:about="http://www.episecc.eu/sem_rep/sem_rep#epi00069">

<rdfs:label xml:lang="en">hasProgress</rdfs:label>




<rdfs:label xml:lang="en">hasCause</rdfs:label>

<rdfs:subPropertyOf rdf:resource="&owl;topDataProperty"/>




<rdfs:label xml:lang="en">hasWaterLevel</rdfs:label>




<rdfs:label xml:lang="en">hasRiskLevel</rdfs:label>




<rdfs:label xml:lang="en">hasMagnitude</rdfs:label>




<rdfs:label xml:lang="en">hasEpicentre</rdfs:label>




www.episecc.eu


<rdfs:label xml:lang="en">hasCapability</rdfs:label>




<rdfs:label xml:lang="en">hasQuantity</rdfs:label>




<rdfs:label xml:lang="en">hasOperationalScope</rdfs:label>




<rdfs:label xml:lang="en">hasSpatialScope</rdfs:label>




<owl:DatatypeProperty rdf:about="http://www.opengis.net/ont/geosparql#asGML">

<rdfs:label xml:lang="en">asGML</rdfs:label>




The GML serialization of a geometry

</skos:definition>



</dc:description>




</rdfs:comment>

<skos:prefLabel xml:lang="en">asGML</skos:prefLabel>


<rdfs:domain rdf:resource="http://www.opengis.net/ont/geosparql#Geometry"/>

www.episecc.eu

<rdfs:range rdf:resource="http://www.opengis.net/ont/geosparql#gmlLiteral"/>

<rdfs:subPropertyOf rdf:resource="http://www.opengis.net/ont/geosparql#hasSerialization"/>





<owl:DatatypeProperty rdf:about="http://www.opengis.net/ont/geosparql#asWKT">

<rdfs:label xml:lang="en">asWKT</rdfs:label>



The WKT serialization of a geometry

</rdfs:comment>



</dc:description>



</skos:definition>



<skos:prefLabel xml:lang="en">asWKT</skos:prefLabel>



<rdfs:subPropertyOf rdf:resource="http://www.opengis.net/ont/geosparql#hasSerialization"/>

<rdfs:range rdf:resource="http://www.opengis.net/ont/geosparql#wktLiteral"/>





<owl:DatatypeProperty rdf:about="http://www.opengis.net/ont/geosparql#coordinateDimension">

<rdfs:label xml:lang="en">coordinateDimension</rdfs:label>





The number of measurements or axes needed to describe the position of this

geometry in a coordinate system.

</skos:definition>




</rdfs:comment>

www.episecc.eu



</dc:description>

<skos:prefLabel xml:lang="en">coordinateDimension</skos:prefLabel>




<rdfs:range rdf:resource="&xsd;integer"/>




<owl:DatatypeProperty rdf:about="http://www.opengis.net/ont/geosparql#dimension">

<rdfs:label xml:lang="en">dimension</rdfs:label>



The topological dimension of this geometric object, which

must be less than or equal to the coordinate dimension.

In non-homogeneous collections, this will return the largest

topological dimension of the contained objects.

</dc:description>






</rdfs:comment>








</skos:definition>

<skos:prefLabel xml:lang="en">dimension</skos:prefLabel>








<owl:DatatypeProperty rdf:about="http://www.opengis.net/ont/geosparql#hasSerialization">

www.episecc.eu

<rdfs:label xml:lang="en">has serialization</rdfs:label>



Connects a geometry object with its text-based serialization.

</rdfs:comment>



</skos:definition>




</dc:description>


<skos:prefLabel xml:lang="en">has serialization</skos:prefLabel>




<rdfs:range rdf:resource="&rdfs;Literal"/>




<owl:DatatypeProperty rdf:about="http://www.opengis.net/ont/geosparql#isEmpty">

<rdfs:label xml:lang="en">isEmpty</rdfs:label>



(true) if this geometric object is the empty Geometry. If

true, then this geometric object represents the empty point

set for the coordinate space.

</dc:description>





</rdfs:comment>





</skos:definition>



<skos:prefLabel xml:lang="en">isEmpty</skos:prefLabel>




<rdfs:range rdf:resource="&xsd;boolean"/>

www.episecc.eu




<owl:DatatypeProperty rdf:about="http://www.opengis.net/ont/geosparql#isSimple">

<rdfs:label xml:lang="en">isSimple</rdfs:label>



(true) if this geometric object has no anomalous geometric

points, such as self intersection or self tangency.

</dc:description>




</rdfs:comment>




</skos:definition>



<skos:prefLabel xml:lang="en">isSimple</skos:prefLabel>




<rdfs:range rdf:resource="&xsd;boolean"/>




<owl:DatatypeProperty rdf:about="http://www.opengis.net/ont/geosparql#spatialDimension">

<rdfs:label xml:lang="en">spatialDimension</rdfs:label>



The number of measurements or axes needed to describe the spatial position of

this geometry in a coordinate system.

</skos:definition>





</rdfs:comment>

www.episecc.eu


</dc:description>

<skos:prefLabel xml:lang="en">spatialDimension</skos:prefLabel>








<rdf:Description rdf:about="&owl;topDataProperty">

<rdf:type rdf:resource="&owl;FunctionalProperty"/>

</rdf:Description>



<owl:DatatypeProperty rdf:about="&skos;notation">

<rdfs:label xml:lang="en">notation</rdfs:label>

<skos:definition xml:lang="en">A notation, also known as classification code, is a string of characters such as "T58.5" or "303.4833" used to uniquely identify a concept within the scope of a given concept scheme.</skos:definition>

<skos:scopeNote xml:lang="en">By convention, skos:notation is used with a typed literal in the object position of the triple.</skos:scopeNote>





<owl:DatatypeProperty rdf:about="http://www.w3.org/2006/time#day">

<rdfs:range rdf:resource="&xsd;gDay"/>





<owl:DatatypeProperty rdf:about="http://www.w3.org/2006/time#dayOfYear">

<rdfs:range rdf:resource="&xsd;nonNegativeInteger"/>

www.episecc.eu



<owl:DatatypeProperty rdf:about="http://www.w3.org/2006/time#days">

<rdfs:range rdf:resource="&xsd;decimal"/>

<rdfs:domain rdf:resource="http://www.w3.org/2006/time#DurationDescription"/>




<owl:DatatypeProperty rdf:about="http://www.w3.org/2006/time#hour">






<owl:DatatypeProperty rdf:about="http://www.w3.org/2006/time#hours">






<owl:DatatypeProperty rdf:about="http://www.w3.org/2006/time#inXSDDateTime">

<rdfs:range rdf:resource="&xsd;dateTime"/>

<rdfs:domain rdf:resource="http://www.w3.org/2006/time#Instant"/>




<owl:DatatypeProperty rdf:about="http://www.w3.org/2006/time#minute">

www.episecc.eu

<owl:DatatypeProperty rdf:about="http://www.w3.org/2006/time#minutes">






<owl:DatatypeProperty rdf:about="http://www.w3.org/2006/time#month">

<rdfs:range rdf:resource="&xsd;gMonth"/>





<owl:DatatypeProperty rdf:about="http://www.w3.org/2006/time#months">






<owl:DatatypeProperty rdf:about="http://www.w3.org/2006/time#second">






<owl:DatatypeProperty rdf:about="http://www.w3.org/2006/time#seconds">






<owl:DatatypeProperty rdf:about="http://www.w3.org/2006/time#week">

www.episecc.eu



<owl:DatatypeProperty rdf:about="http://www.w3.org/2006/time#weeks">






<owl:DatatypeProperty rdf:about="http://www.w3.org/2006/time#xsdDateTime">

<rdfs:range rdf:resource="&xsd;dateTime"/>

<rdfs:domain rdf:resource="http://www.w3.org/2006/time#DateTimeInterval"/>




<owl:DatatypeProperty rdf:about="http://www.w3.org/2006/time#year">

<rdfs:range rdf:resource="&xsd;gYear"/>





<owl:DatatypeProperty rdf:about="http://www.w3.org/2006/time#years">

www.episecc.eu



<owl:Class rdf:about="http://webprotege.stanford.edu/epi00091">

<rdfs:label>Disaster</rdfs:label>

<rdfs:subClassOf rdf:resource="http://www.episecc.eu/sem_rep/sem_rep#epi00056"/>

<rdfs:comment>“Disaster means any situation which has or may have a severe impact on people, the environment, or property, including cultural heritage.” (DECISION No 1313/2013/EU OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 17 December 2013 on a Union Civil Protection Mechanism)</rdfs:comment>

</owl:Class>



<rdfs:label>Resource</rdfs:label>


<rdfs:comment>Assets an organisation has available for the response to a critical event.</rdfs:comment>

</owl:Class>



<rdfs:label>Process</rdfs:label>


<rdfs:comment>Process is a set of actions aiming for a certain result, executed by an organisation during a response to a critical event.</rdfs:comment>

</owl:Class>



<rdfs:label>Interaction with people</rdfs:label>

<rdfs:subClassOf rdf:resource="http://webprotege.stanford.edu/epi00093"/>

<rdfs:comment>Mutual interaction between organisations and affected people.</rdfs:comment>

</owl:Class>



<rdfs:label>Physical response</rdfs:label>


www.episecc.eu


<rdfs:comment>An organised activity to physically cope with the immediate aftermath of a disaster.</rdfs:comment>

</owl:Class>



<rdfs:label>Command and control</rdfs:label>


<rdfs:comment>Distribution of results of a decision-making process.</rdfs:comment>

</owl:Class>



<rdfs:label>Resources management</rdfs:label>


<rdfs:comment>Allocating and using resources during a response to a critical event.</rdfs:comment>

</owl:Class>



<rdfs:label>Interoperability actions</rdfs:label>


<rdfs:comment>Exchanging information between different organisational units using communication media and tools.</rdfs:comment>

</owl:Class>



<rdfs:label>Human</rdfs:label>


<rdfs:comment>Workforce an organisation has available for the response to a critical event.</rdfs:comment>

</owl:Class>



www.episecc.eu



<rdfs:label>Institutional</rdfs:label>


<rdfs:comment>Organisational and managerial assets an organisation developed for the response to a critical event.</rdfs:comment>

</owl:Class>



<rdfs:label>Physical</rdfs:label>


<rdfs:comment>A tangible assets an organisation has available for the response to a critical event.</rdfs:comment>

</owl:Class>



<rdfs:label>Finacial</rdfs:label>


<rdfs:comment>Finances and related assets an organisation has available for the response to a critical event.</rdfs:comment>

</owl:Class>



<rdfs:label>Animal</rdfs:label>


<rdfs:comment>An animal used by first responders during a response to a critical event.</rdfs:comment>

</owl:Class>



<rdfs:label>Storm surge</rdfs:label>


<rdfs:comment>Rise of the water level in the sea, an estuary or lake as result of strong wind driving the



www.episecc.eu

seawater towards the coast.</rdfs:comment>

</owl:Class>



<rdfs:label>Landslide</rdfs:label>


<rdfs:comment>A movement of soil or rock controlled by gravity and the speed of the movement usually ranges between slow and rapid, but not very slow.</rdfs:comment>

</owl:Class>



<rdfs:label>Storm</rdfs:label>


<rdfs:comment>Any disturbed state of an environment or astronomical body's atmosphere especially affecting its surface, and strongly implying severe weather.</rdfs:comment>

</owl:Class>



<rdfs:label>Cold wave</rdfs:label>


<rdfs:comment>A prolonged period of excessively cold weather and the sudden invasion of very cold air over a large area.</rdfs:comment>

</owl:Class>



<rdfs:label>Transport accidents</rdfs:label>


<rdfs:comment>Technological transport accidents involving mechanised modes of transport.</rdfs:comment>

</owl:Class>




www.episecc.eu


<rdfs:label>Subsidence</rdfs:label>


<rdfs:comment>A motion of the Earth's surface as it shifts downward relative to a the sea level.</rdfs:comment>

</owl:Class>



<rdfs:label>Volcanic eruption</rdfs:label>


<rdfs:comment>A discharge of lava and gas from a volcanic vent.</rdfs:comment>

</owl:Class>



<rdfs:label>Earthquake</rdfs:label>


<rdfs:comment>Sudden break within the upper layers of the earth, sometimes breaking the surface, resulting in the vibration of the ground, which where strong enough will cause the collapse of buildings and destruction of life and property.</rdfs:comment>

</owl:Class>



<rdfs:label>Tsunami</rdfs:label>


<rdfs:comment>A series of waves caused by a rapid displacement of a body of water.</rdfs:comment>

</owl:Class>



<rdfs:label>Avalanche</rdfs:label>


<rdfs:comment>A quantity of snow or ice that slides down a mountainside under the force of gravity.</rdfs:comment>

</owl:Class>



www.episecc.eu



<rdfs:label>Fire</rdfs:label>


<rdfs:comment>An uncontrolled burning fire.</rdfs:comment>

</owl:Class>



<rdfs:label>Industrial disaster</rdfs:label>


<rdfs:comment>Danger originating from technological or industrial accidents, dangerous procedures, infrastructure failures or certain human activities.</rdfs:comment>

</owl:Class>



<rdfs:label>Rockfall</rdfs:label>


<rdfs:comment>Quantities of rock or stone falling freely from a cliff face.</rdfs:comment>

</owl:Class>



<rdfs:label>Debris flow</rdfs:label>


<rdfs:comment>Downhill sliding or falling movement of soil and rock.</rdfs:comment>

</owl:Class>



<rdfs:label>Refugee crisis</rdfs:label>




www.episecc.eu

<rdfs:comment>A huge number of people fleeing from a danger or a problem.</rdfs:comment>

</owl:Class>



<rdfs:label>Migrant crisis</rdfs:label>


<rdfs:comment>A huge number of people who moves from one place to another in order to find work or better living conditions.</rdfs:comment>

</owl:Class>



<rdfs:label>Heat wave</rdfs:label>


<rdfs:comment>A prolonged period of excessively hot and sometimes also humid weather relative to normal climate patterns of a certain region.</rdfs:comment>

</owl:Class>



<rdfs:label>Flood</rdfs:label>


<rdfs:comment>A temporary covering by water of land not normally covered by water.</rdfs:comment>

</owl:Class>



<rdfs:label>Process priority</rdfs:label>

<owl:equivalentClass>

<owl:Class>

<owl:oneOf rdf:parseType="Collection">

<rdf:Description rdf:about="http://www.episecc.eu/sem_rep#epi00285"/>



</owl:oneOf>



www.episecc.eu

</owl:Class>

</owl:equivalentClass>

<rdfs:comment>A process status related to its importance.</rdfs:comment>

</owl:Class>



<rdfs:label>Disaster cause</rdfs:label>

<rdfs:comment>A person or thing that gives rise to a disaster.</rdfs:comment>

</owl:Class>



<rdfs:label>Resource status</rdfs:label>


<owl:Class>





</owl:oneOf>

</owl:Class>


<rdfs:comment>The status of the resource regarding its availability for deployment.</rdfs:comment>

</owl:Class>



<rdfs:label>Disaster object</rdfs:label>


<rdfs:comment>A category of a disaster having common characteristics related to the object of an impact.</rdfs:comment>

</owl:Class>



<rdfs:label>Organisation</rdfs:label>



www.episecc.eu

<rdfs:comment>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.</rdfs:comment>

</owl:Class>



<rdfs:label>Process status</rdfs:label>

<rdfs:comment>The position of the process related to its completion.</rdfs:comment>

</owl:Class>



<rdfs:label>Organisation operational scope</rdfs:label>

<rdfs:comment>Scope related to the decision-making level.</rdfs:comment>

</owl:Class>



<rdfs:label>Organisation spatial scope</rdfs:label>

<rdfs:comment>Spatial scope of organisation's activities and/or presence.</rdfs:comment>

</owl:Class>



<rdfs:label>Search and rescue operations</rdfs:label>


<rdfs:comment>Search for and provision of aid to people who are in distress or imminent danger.</rdfs:comment>

</owl:Class>



<rdfs:label>Civil protection</rdfs:label>



www.episecc.eu


<rdfs:comment>Protection of life and property in the event of a disaster.</rdfs:comment>

</owl:Class>



<rdfs:label>Recovery of cultural heritage</rdfs:label>


<rdfs:comment>Protection of cultural heritage in the event of a disaster.</rdfs:comment>

</owl:Class>



<rdfs:label>Governamental</rdfs:label>


<rdfs:comment>An organisation that is a part of a government.</rdfs:comment>

</owl:Class>



<rdfs:label>Private</rdfs:label>


<rdfs:comment>An organisation performing a conventional for-profit business.</rdfs:comment>

</owl:Class>



<rdfs:label>Non-governamental</rdfs:label>


<rdfs:comment>An organisation that is neither a part of a government nor a conventional for-profit business.</rdfs:comment>

</owl:Class>




www.episecc.eu


<rdfs:label>Humanitarian assistance</rdfs:label>


<rdfs:comment>Material or logistical assistance provided for humanitarian purposes.</rdfs:comment>

</owl:Class>



<rdfs:label>Emegency medical assistance</rdfs:label>


<rdfs:comment>Treatment and transport of people that may be life threatening or injured during a response to a critical event.</rdfs:comment>

</owl:Class>



<rdfs:label xml:lang="en">Environment</rdfs:label>


<rdfs:comment>A disaster which includes impact on nature/environment.</rdfs:comment>

</owl:Class>



<rdfs:label xml:lang="en">People and environment</rdfs:label>


<rdfs:comment xml:lang="en">A disaster which impacts people in terms of health, safety or well being of a community and nature/environment.</rdfs:comment>

</owl:Class>



<rdfs:label xml:lang="en">Environment and property</rdfs:label>


<rdfs:comment xml:lang="en">A disaster which impacts nature/environment and property including cultural heritage.</rdfs:comment>

</owl:Class>



www.episecc.eu



<rdfs:label xml:lang="en">People</rdfs:label>


<rdfs:comment>A disaster which predominantly impacts people in terms of health, safety or well being of a community.</rdfs:comment>

</owl:Class>



<rdfs:label>Property</rdfs:label>


<rdfs:comment>A disaster which includes impact on property including cultural heritage.</rdfs:comment>

</owl:Class>



<rdfs:label xml:lang="en">People and property</rdfs:label>


<rdfs:comment>A disaster which impacts people in terms of health, safety or well being of a community and property.</rdfs:comment>

</owl:Class>



<rdfs:label xml:lang="en">People, environment and property</rdfs:label>


<rdfs:comment xml:lang="en">A disaster which impacts people in terms of health, safety or well being of a community, nature/environment and property including cultural heritage.</rdfs:comment>

</owl:Class>


<owl:Class rdf:about="http://www.episecc.eu/sem_rep#epi00259">

<rdfs:label xml:lang="en">Affected people data</rdfs:label>



www.episecc.eu


<rdfs:comment xml:lang="en">Data about people affected by a disaster.</rdfs:comment>

</owl:Class>



<rdfs:label xml:lang="en">Casualties</rdfs:label>

<rdfs:subClassOf rdf:resource="http://www.episecc.eu/sem_rep#epi00259"/>

<rdfs:comment xml:lang="en">Data about people who are killed or injured during a disaster.</rdfs:comment>

</owl:Class>



<rdfs:label xml:lang="en">Homeless</rdfs:label>


<rdfs:comment xml:lang="en">The number of individuals reported needing immediate assistance for shelter.</rdfs:comment>

</owl:Class>



<rdfs:label xml:lang="en">Missing</rdfs:label>


<rdfs:comment xml:lang="en">The number of individuals reported or presumed missing.</rdfs:comment>

</owl:Class>



<rdfs:label xml:lang="en">Total affected</rdfs:label>


<rdfs:comment xml:lang="en">The total number of affected people.</rdfs:comment>

</owl:Class>



www.episecc.eu



<rdfs:label xml:lang="en">Injured with high priority</rdfs:label>


<rdfs:comment xml:lang="en">The number of individuals reported injured with high priority for medical intervention.</rdfs:comment>

</owl:Class>



<rdfs:label xml:lang="en">Injured with low priority</rdfs:label>


<rdfs:comment xml:lang="en">The number of individuals reported injured with low priority for medical intervention.</rdfs:comment>

</owl:Class>



<rdfs:label xml:lang="en">Killed</rdfs:label>


<rdfs:comment xml:lang="en">The number of individuals reported or presumed killed.</rdfs:comment>

</owl:Class>



<rdfs:label xml:lang="en">Damage data</rdfs:label>


<rdfs:comment xml:lang="en">Estimated damages of relevant infrastructures and/or buildings.</rdfs:comment>

</owl:Class>



<rdfs:label xml:lang="en">Decontamination</rdfs:label>


<rdfs:comment xml:lang="en">Cleaning equipment, infrastructure, terrain, humans or area to remove contaminants including CBRN.</rdfs:comment>



www.episecc.eu

</owl:Class>



<rdfs:label xml:lang="en">Extinguishing fire</rdfs:label>


<rdfs:comment xml:lang="en">An act undertaken to terminate fire.</rdfs:comment>

</owl:Class>



<rdfs:label xml:lang="en">Recovery</rdfs:label>


<rdfs:comment xml:lang="en">Act of returning into function or saving affected infrastructure, property, environment and cultural heritage after a disaster has hit.</rdfs:comment>

</owl:Class>



<rdfs:label xml:lang="en">Rescue of animals</rdfs:label>


<rdfs:comment xml:lang="en">An act of saving affected animals from danger after a disaster has hit.</rdfs:comment>

</owl:Class>



<rdfs:label xml:lang="en">Rescue of people</rdfs:label>


<rdfs:comment xml:lang="en">An act of saving affected people from danger after a disaster has hit.</rdfs:comment>

</owl:Class>




www.episecc.eu


<rdfs:label xml:lang="en">Search for animals</rdfs:label>


<rdfs:comment xml:lang="en">An act of finding affected animals after a disaster has hit.</rdfs:comment>

</owl:Class>



<rdfs:label xml:lang="en">Search for people</rdfs:label>


<rdfs:comment xml:lang="en">An act of finding affected people after a disaster has hit.</rdfs:comment>

</owl:Class>



<rdfs:label xml:lang="en">Securing</rdfs:label>


<rdfs:comment xml:lang="en">Securing dangerous objects or materials.</rdfs:comment>

</owl:Class>



<rdfs:label xml:lang="en">Providing resources to a disaster area</rdfs:label>


<rdfs:comment xml:lang="en">Delivering resources and services to a disaster area.</rdfs:comment>

</owl:Class>



<rdfs:label xml:lang="en">Providing supplies to first responders</rdfs:label>


<rdfs:comment xml:lang="en">Delivering requested supplies and services to first responders on a disaster area.</rdfs:comment>

</owl:Class>



www.episecc.eu



<rdfs:label xml:lang="en">Providing supplies to people</rdfs:label>


<rdfs:comment xml:lang="en">Delivering requested supplies and services to people affected by a disaster.</rdfs:comment>

</owl:Class>



<rdfs:label xml:lang="en">Equipment</rdfs:label>


<rdfs:comment xml:lang="en">Supplies or tools used by an organisation during a response to a critical event.</rdfs:comment>

</owl:Class>



<rdfs:label xml:lang="en">Infrastructure</rdfs:label>


<rdfs:comment xml:lang="en">Physical and organizational structures, systems and facilities needed for the operation during the response to a critical event.</rdfs:comment>

</owl:Class>


<owl:Class rdf:about="http://www.episecc.eu/sem_rep/sem_rep#epi00053">

<rdfs:label xml:lang="en">Common operational picture</rdfs:label>

</owl:Class>



<rdfs:label xml:lang="en">Static data</rdfs:label>


</owl:Class>



www.episecc.eu



<rdfs:label xml:lang="en">Dynamic data</rdfs:label>


</owl:Class>



<rdfs:label xml:lang="en">Situational data</rdfs:label>


</owl:Class>



<rdfs:label xml:lang="en">Operational data</rdfs:label>


</owl:Class>



<rdfs:label xml:lang="en">Capability</rdfs:label>

<rdfs:comment xml:lang="en">Ability to response to a disaster in relation to capacity.</rdfs:comment>

</owl:Class>



<rdfs:label xml:lang="en">Quantity</rdfs:label>

</owl:Class>



www.episecc.eu


<rdfs:label xml:lang="en">Water reservoir</rdfs:label>


</owl:Class>



<rdfs:label xml:lang="en">Water level</rdfs:label>

</owl:Class>



<rdfs:label xml:lang="en">Risk level</rdfs:label>

</owl:Class>



<rdfs:label xml:lang="en">Magnitude</rdfs:label>

</owl:Class>



<rdfs:label xml:lang="en">Epicentre</rdfs:label>

</owl:Class>



<rdfs:label xml:lang="en">Spatiotemporal part</rdfs:label>

</owl:Class>

www.episecc.eu

<owl:Class rdf:about="http://www.opengis.net/ont/geosparql#Feature">

<rdfs:label xml:lang="en">Feature</rdfs:label>

<rdfs:subClassOf rdf:resource="http://www.opengis.net/ont/geosparql#SpatialObject"/>

<owl:disjointWith rdf:resource="http://www.opengis.net/ont/geosparql#Geometry"/>



This class represents the top-level feature type. This class is

equivalent to GFI_Feature defined in ISO 19156:2011, and it is

superclass of all feature types.

</skos:definition>





</rdfs:comment>






</dc:description>


<skos:prefLabel xml:lang="en">Feature</skos:prefLabel>


<rdfs:isDefinedBy rdf:resource="http://www.opengis.net/ont/gml"/>


</owl:Class>



<owl:Class rdf:about="http://www.opengis.net/ont/geosparql#Geometry">

<rdfs:label xml:lang="en">Geometry</rdfs:label>

<rdfs:subClassOf rdf:resource="http://www.opengis.net/ont/geosparql#SpatialObject"/>



The class represents the top-level geometry type. This class is

equivalent to the UML class GM_Object defined in ISO 19107, and

it is superclass of all geometry types.

</dc:description>





</skos:definition>

www.episecc.eu




</rdfs:comment>

<skos:prefLabel xml:lang="en">Geometry</skos:prefLabel>




</owl:Class>



<owl:Class rdf:about="http://www.opengis.net/ont/geosparql#SpatialObject">

<rdfs:label xml:lang="en">SpatialObject</rdfs:label>



The class spatial-object represents everything that can have

a spatial representation. It is superclass of feature and geometry.

</rdfs:comment>




</skos:definition>




</dc:description>



<skos:prefLabel xml:lang="en">SpatialObject</skos:prefLabel>




</owl:Class>



<owl:Class rdf:about="http://www.opengis.net/ont/gml#AbstractCurveSegment">

<rdfs:label xml:lang="en">Abstract Curve Segment</rdfs:label>

<rdfs:subClassOf rdf:resource="http://www.opengis.net/ont/geosparql#Geometry"/>


</owl:Class>

www.episecc.eu



<owl:Class rdf:about="http://www.opengis.net/ont/gml#AbstractGeometricPrimitive">

<rdfs:label xml:lang="en">Abstract Geometric Primitive</rdfs:label>

<rdfs:subClassOf rdf:resource="http://www.opengis.net/ont/gml#AbstractGeometry"/>


</owl:Class>



<owl:Class rdf:about="http://www.opengis.net/ont/gml#AbstractGeometry">

<rdfs:label xml:lang="en">Abstract Geometry</rdfs:label>



</owl:Class>



<owl:Class rdf:about="http://www.opengis.net/ont/gml#AbstractGriddedSurface">

<rdfs:label xml:lang="en">Abstract Gridded Surface</rdfs:label>

<rdfs:subClassOf rdf:resource="http://www.opengis.net/ont/gml#AbstractParametricCurveSurface"/>


</owl:Class>



<owl:Class rdf:about="http://www.opengis.net/ont/gml#AbstractParametricCurveSurface">

<rdfs:label xml:lang="en">Abstract Parametric Curve Surface</rdfs:label>

<rdfs:subClassOf rdf:resource="http://www.opengis.net/ont/gml#AbstractSurfacePatch"/>


</owl:Class>



<owl:Class rdf:about="http://www.opengis.net/ont/gml#AbstractSurfacePatch">

<rdfs:label xml:lang="en">Abstract Surface Patch</rdfs:label>



</owl:Class>

www.episecc.eu



<owl:Class rdf:about="http://www.opengis.net/ont/gml#Arc">

<rdfs:label xml:lang="en">Arc</rdfs:label>

<rdfs:subClassOf rdf:resource="http://www.opengis.net/ont/gml#ArcString"/>


</owl:Class>



<owl:Class rdf:about="http://www.opengis.net/ont/gml#ArcByBulge">

<rdfs:label xml:lang="en">Arc by Bulge</rdfs:label>

<rdfs:subClassOf rdf:resource="http://www.opengis.net/ont/gml#ArcStringByBulge"/>


</owl:Class>



<owl:Class rdf:about="http://www.opengis.net/ont/gml#ArcByCenterPoint">

<rdfs:label xml:lang="en">Arc by Center Point</rdfs:label>

<rdfs:subClassOf rdf:resource="http://www.opengis.net/ont/gml#AbstractCurveSegment"/>


</owl:Class>



<owl:Class rdf:about="http://www.opengis.net/ont/gml#ArcString">

<rdfs:label xml:lang="en">Arc String</rdfs:label>



</owl:Class>



<owl:Class rdf:about="http://www.opengis.net/ont/gml#ArcStringByBulge">

<rdfs:label xml:lang="en">Arc String by Bulge</rdfs:label>



</owl:Class>

www.episecc.eu



<owl:Class rdf:about="http://www.opengis.net/ont/gml#BSpline">

<rdfs:label xml:lang="en">BSpline</rdfs:label>

<rdfs:subClassOf rdf:resource="http://www.opengis.net/ont/gml#SplineCurve"/>


</owl:Class>



<owl:Class rdf:about="http://www.opengis.net/ont/gml#Bezier">

<rdfs:label xml:lang="en">Bezier</rdfs:label>

<rdfs:subClassOf rdf:resource="http://www.opengis.net/ont/gml#BSpline"/>


</owl:Class>



<owl:Class rdf:about="http://www.opengis.net/ont/gml#Circle">

<rdfs:label xml:lang="en">Circle</rdfs:label>

<rdfs:subClassOf rdf:resource="http://www.opengis.net/ont/gml#Arc"/>


</owl:Class>



<owl:Class rdf:about="http://www.opengis.net/ont/gml#CircleByCenterPoint">

<rdfs:label xml:lang="en">CircleByCenterPoint</rdfs:label>

<rdfs:subClassOf rdf:resource="http://www.opengis.net/ont/gml#ArcByCenterPoint"/>


</owl:Class>



<owl:Class rdf:about="http://www.opengis.net/ont/gml#Clothoid">

<rdfs:label xml:lang="en">Clothoid</rdfs:label>



</owl:Class>

www.episecc.eu



<owl:Class rdf:about="http://www.opengis.net/ont/gml#Composite">

<rdfs:label xml:lang="en">Composite</rdfs:label>

<rdfs:subClassOf rdf:resource="http://www.opengis.net/ont/gml#GeometricComplex"/>


</owl:Class>



<owl:Class rdf:about="http://www.opengis.net/ont/gml#CompositeCurve">

<rdfs:label xml:lang="en">Composite Curve</rdfs:label>

<rdfs:subClassOf rdf:resource="http://www.opengis.net/ont/gml#Composite"/>

<rdfs:subClassOf rdf:resource="http://www.opengis.net/ont/gml#OrientableCurve"/>


</owl:Class>



<owl:Class rdf:about="http://www.opengis.net/ont/gml#CompositeSolid">

<rdfs:label xml:lang="en">Composite Solid</rdfs:label>


<rdfs:subClassOf rdf:resource="http://www.opengis.net/ont/gml#Solid"/>


</owl:Class>



<owl:Class rdf:about="http://www.opengis.net/ont/gml#CompositeSurface">

<rdfs:label xml:lang="en">Composite Surface</rdfs:label>


<rdfs:subClassOf rdf:resource="http://www.opengis.net/ont/gml#OrientableSurface"/>


</owl:Class>



<owl:Class rdf:about="http://www.opengis.net/ont/gml#Cone">

www.episecc.eu

<rdfs:label xml:lang="en">Cone</rdfs:label>

<rdfs:subClassOf rdf:resource="http://www.opengis.net/ont/gml#AbstractGriddedSurface"/>


</owl:Class>



<owl:Class rdf:about="http://www.opengis.net/ont/gml#CubicSpline">

<rdfs:label xml:lang="en">Cubic Spline</rdfs:label>

<rdfs:subClassOf rdf:resource="http://www.opengis.net/ont/gml#PolynomialSpline"/>


</owl:Class>



<owl:Class rdf:about="http://www.opengis.net/ont/gml#Curve">

<rdfs:label xml:lang="en">Curve</rdfs:label>

<rdfs:subClassOf rdf:resource="http://www.opengis.net/ont/gml#AbstractGeometricPrimitive"/>

<rdfs:subClassOf rdf:resource="http://www.opengis.net/ont/gml#OrientableCurve"/>


</owl:Class>



<owl:Class rdf:about="http://www.opengis.net/ont/gml#Cylinder">

<rdfs:label xml:lang="en">Cylinder</rdfs:label>



</owl:Class>



<owl:Class rdf:about="http://www.opengis.net/ont/gml#Geodesic">

<rdfs:label xml:lang="en">Geodesic</rdfs:label>

<rdfs:subClassOf rdf:resource="http://www.opengis.net/ont/gml#GeodesicString"/>


</owl:Class>

www.episecc.eu

<owl:Class rdf:about="http://www.opengis.net/ont/gml#GeodesicString">

<rdfs:label xml:lang="en">Geodesic String</rdfs:label>



</owl:Class>



<owl:Class rdf:about="http://www.opengis.net/ont/gml#GeometricComplex">

<rdfs:label xml:lang="en">Geometric Complex</rdfs:label>



</owl:Class>



<owl:Class rdf:about="http://www.opengis.net/ont/gml#LineString">

<rdfs:label xml:lang="en">Line String</rdfs:label>

<rdfs:subClassOf rdf:resource="http://www.opengis.net/ont/gml#LineStringSegment"/>


</owl:Class>



<owl:Class rdf:about="http://www.opengis.net/ont/gml#LineStringSegment">

<rdfs:label xml:lang="en">Line String Segment</rdfs:label>



</owl:Class>



<owl:Class rdf:about="http://www.opengis.net/ont/gml#LinearRing">

<rdfs:label xml:lang="en">Linear Ring</rdfs:label>

<rdfs:subClassOf rdf:resource="http://www.opengis.net/ont/gml#Ring"/>


</owl:Class>

www.episecc.eu



<owl:Class rdf:about="http://www.opengis.net/ont/gml#MultiCurve">

<rdfs:label xml:lang="en">Multi-Curve</rdfs:label>

<rdfs:subClassOf rdf:resource="http://www.opengis.net/ont/gml#MultiGeometry"/>


</owl:Class>



<owl:Class rdf:about="http://www.opengis.net/ont/gml#MultiGeometry">

<rdfs:label xml:lang="en">Multi-Geometry</rdfs:label>



</owl:Class>



<owl:Class rdf:about="http://www.opengis.net/ont/gml#MultiPoint">

<rdfs:label xml:lang="en">Multi-Point</rdfs:label>



</owl:Class>



<owl:Class rdf:about="http://www.opengis.net/ont/gml#MultiSolid">

<rdfs:label xml:lang="en">Multi-Solid</rdfs:label>



</owl:Class>



<owl:Class rdf:about="http://www.opengis.net/ont/gml#MultiSurface">

<rdfs:label xml:lang="en">Multi-Surface</rdfs:label>



</owl:Class>

www.episecc.eu



<owl:Class rdf:about="http://www.opengis.net/ont/gml#OffsetCurve">

<rdfs:label xml:lang="en">Offset Curve</rdfs:label>



</owl:Class>



<owl:Class rdf:about="http://www.opengis.net/ont/gml#OrientableCurve">

<rdfs:label xml:lang="en">Orientable Curve</rdfs:label>



</owl:Class>



<owl:Class rdf:about="http://www.opengis.net/ont/gml#OrientableSurface">

<rdfs:label xml:lang="en">Orientable Surface</rdfs:label>



</owl:Class>



<owl:Class rdf:about="http://www.opengis.net/ont/gml#Point">

<rdfs:label xml:lang="en">Point</rdfs:label>



</owl:Class>



<owl:Class rdf:about="http://www.opengis.net/ont/gml#Polygon">

<rdfs:label xml:lang="en">Polygon</rdfs:label>

<rdfs:subClassOf rdf:resource="http://www.opengis.net/ont/gml#Surface"/>


</owl:Class>

www.episecc.eu



<owl:Class rdf:about="http://www.opengis.net/ont/gml#PolygonPatch">

<rdfs:label xml:lang="en">Polygon Patch</rdfs:label>

<rdfs:subClassOf rdf:resource="http://www.opengis.net/ont/gml#AbstractSurfacePatch"/>


</owl:Class>



<owl:Class rdf:about="http://www.opengis.net/ont/gml#PolyhedralSurface">

<rdfs:label xml:lang="en">Polyhedral Surface</rdfs:label>

<rdfs:subClassOf rdf:resource="http://www.opengis.net/ont/gml#Surface"/>


</owl:Class>



<owl:Class rdf:about="http://www.opengis.net/ont/gml#PolynomialSpline">

<rdfs:label xml:lang="en">Polynomial Spline</rdfs:label>

<rdfs:subClassOf rdf:resource="http://www.opengis.net/ont/gml#SplineCurve"/>


</owl:Class>



<owl:Class rdf:about="http://www.opengis.net/ont/gml#Rectangle">

<rdfs:label xml:lang="en">Rectangle</rdfs:label>

<rdfs:subClassOf rdf:resource="http://www.opengis.net/ont/gml#PolygonPatch"/>


</owl:Class>



<owl:Class rdf:about="http://www.opengis.net/ont/gml#Ring">

<rdfs:label xml:lang="en">Ring</rdfs:label>

<rdfs:subClassOf rdf:resource="http://www.opengis.net/ont/gml#CompositeCurve"/>


</owl:Class>

www.episecc.eu



<owl:Class rdf:about="http://www.opengis.net/ont/gml#Shell">

<rdfs:label xml:lang="en">Shell</rdfs:label>

<rdfs:subClassOf rdf:resource="http://www.opengis.net/ont/gml#CompositeSurface"/>


</owl:Class>



<owl:Class rdf:about="http://www.opengis.net/ont/gml#Solid">

<rdfs:label xml:lang="en">Solid</rdfs:label>



</owl:Class>



<owl:Class rdf:about="http://www.opengis.net/ont/gml#Sphere">

<rdfs:label xml:lang="en">Sphere</rdfs:label>



</owl:Class>



<owl:Class rdf:about="http://www.opengis.net/ont/gml#SplineCurve">

<rdfs:label xml:lang="en">Spline Curve</rdfs:label>



</owl:Class>



<owl:Class rdf:about="http://www.opengis.net/ont/gml#Surface">

<rdfs:label xml:lang="en">Surface</rdfs:label>


<rdfs:subClassOf rdf:resource="http://www.opengis.net/ont/gml#OrientableSurface"/>

www.episecc.eu


</owl:Class>



<owl:Class rdf:about="http://www.opengis.net/ont/gml#Tin">

<rdfs:label xml:lang="en">Triangulated Irregular Network</rdfs:label>

<rdfs:subClassOf rdf:resource="http://www.opengis.net/ont/gml#TriangulatedSurface"/>


</owl:Class>



<owl:Class rdf:about="http://www.opengis.net/ont/gml#Triangle">

<rdfs:label xml:lang="en">Triangle</rdfs:label>

<rdfs:subClassOf rdf:resource="http://www.opengis.net/ont/gml#PolygonPatch"/>


</owl:Class>



<owl:Class rdf:about="http://www.opengis.net/ont/gml#TriangulatedSurface">

<rdfs:label xml:lang="en">Triangulated Surface</rdfs:label>

<rdfs:subClassOf rdf:resource="http://www.opengis.net/ont/gml#PolyhedralSurface"/>


</owl:Class>



<owl:Class rdf:about="http://www.opengis.net/ont/sf#Curve">

<rdfs:label xml:lang="en">Curve</rdfs:label>

<rdfs:subClassOf rdf:resource="http://www.opengis.net/ont/sf#Geometry"/>


A Curve is a 1-dimensional geometric object usually stored as a sequence of Points, with the subtype of Curve specifying the form of the interpolation between Points. This specification defines only one subclass of Curve, LineString, which uses linear interpolation between Points.

A Curve is a 1-dimensional geometric object that is the homeomorphic image of a real, closed, interval.

A Curve is simple if it does not pass through the same Point twice with the possible exception of the two end

points.

A Curve is closed if its start Point is equal to its end Point.

The boundary of a closed Curve is empty.

www.episecc.eu

A Curve that is simple and closed is a Ring.

The boundary of a non-closed Curve consists of its two end Points.

A Curve is defined as topologically closed, that is, it contains its endpoints f(a) and f(b).

</rdfs:comment>

<rdfs:isDefinedBy rdf:resource="http://www.opengis.net/ont/sf"/>

</owl:Class>



<owl:Class rdf:about="http://www.opengis.net/ont/sf#Geometry">

<rdfs:label xml:lang="en">Geometry</rdfs:label>



Geometry is the root class of the hierarchy.

The instantiable subclasses of Geometry are restricted to 0, 1 and 2-dimensional geometric objects that exist in 2, 3 or 4-dimensional coordinate space (R2, R3 or R4). Geometry values in R2 have points with coordinate values for x and y. Geometry values in R3 have points with coordinate values for x, y and z or for x, y and m. Geometry values in R4 have points with coordinate values for x, y, z and m.

The interpretation of the coordinates is subject to the coordinate reference systems associated to the point. All coordinates within a geometry object should be in the same coordinate reference systems. Each coordinate shall be unambiguously associated to a coordinate reference system either directly or through its containing geometry. The z coordinate of a point is typically, but not necessarily, represents altitude or elevation. The m coordinate represents a measurement.

All Geometry classes described in this specification are defined so that instances of Geometry are topologically closed, i.e. all represented geometries include their boundary as point sets. This does not affect their representation, and open version of the same classes may be used in other circumstances, such as topological representations.

</rdfs:comment>


</owl:Class>



<owl:Class rdf:about="http://www.opengis.net/ont/sf#GeometryCollection">

<rdfs:label xml:lang="en">Geometry Collection</rdfs:label>



A GeometryCollection is a geometric object that is a collection of some number of geometric objects.

All the elements in a GeometryCollection shall be in the same Spatial Reference System. This is also the Spatial Reference System for the GeometryCollection.

GeometryCollection places no other constraints on its elements. Subclasses of GeometryCollection may restrict membership based on dimension and may also place other constraints on the degree of spatial overlap between elements.

</rdfs:comment>


</owl:Class>

www.episecc.eu



<owl:Class rdf:about="http://www.opengis.net/ont/sf#Line">

<rdfs:label xml:lang="en">Line</rdfs:label>

<rdfs:subClassOf rdf:resource="http://www.opengis.net/ont/sf#LineString"/>


A Line is a LineString with exactly 2 Points.

</rdfs:comment>


</owl:Class>



<owl:Class rdf:about="http://www.opengis.net/ont/sf#LineString">

<rdfs:label xml:lang="en">Line String</rdfs:label>

<rdfs:subClassOf rdf:resource="http://www.opengis.net/ont/sf#Curve"/>


A LineString is a Curve with linear interpolation between Points. Each consecutive pair of Points defines a Line segment.

</rdfs:comment>


</owl:Class>



<owl:Class rdf:about="http://www.opengis.net/ont/sf#LinearRing">

<rdfs:label xml:lang="en">Linear Ring</rdfs:label>

<rdfs:subClassOf rdf:resource="http://www.opengis.net/ont/sf#LineString"/>


A LinearRing is a LineString that is both closed and simple.

</rdfs:comment>


</owl:Class>



<owl:Class rdf:about="http://www.opengis.net/ont/sf#MultiCurve">

<rdfs:label xml:lang="en">Multi Curve</rdfs:label>

<rdfs:subClassOf rdf:resource="http://www.opengis.net/ont/sf#GeometryCollection"/>


A MultiCurve is a 1-dimensional GeometryCollection whose elements are Curves.

www.episecc.eu

A MultiCurve defines a set of methods for its subclasses and is included for reasons of extensibility.

A MultiCurve is simple if and only if all of its elements are simple and the only intersections between any two elements occur at Points that are on the boundaries of both elements.

The boundary of a MultiCurve is obtained by applying the mod 2 union rule: A Point is in the boundary of a MultiCurve if it is in the boundaries of an odd number of elements of the MultiCurve.

A MultiCurve is closed if all of its elements are closed. The boundary of a closed MultiCurve is always empty.

A MultiCurve is defined as topologically closed.

</rdfs:comment>


</owl:Class>



<owl:Class rdf:about="http://www.opengis.net/ont/sf#MultiLineString">

<rdfs:label xml:lang="en">Multi Line String</rdfs:label>

<rdfs:subClassOf rdf:resource="http://www.opengis.net/ont/sf#MultiCurve"/>


A MultiLineString is a MultiCurve whose elements are LineStrings.

</rdfs:comment>


</owl:Class>



<owl:Class rdf:about="http://www.opengis.net/ont/sf#MultiPoint">

<rdfs:label xml:lang="en">Multi Point</rdfs:label>



A MultiPoint is a 0-dimensional GeometryCollection. The elements of a MultiPoint are restricted to Points. ThePoints are not connected or ordered in any semantically important way.

A MultiPoint is simple if no two Points in the MultiPoint are equal (have identical coordinate values in X and Y).

Every MultiPoint is spatially equal to a simple Multipoint.

The boundary of a MultiPoint is the empty set.

</rdfs:comment>


</owl:Class>



<owl:Class rdf:about="http://www.opengis.net/ont/sf#MultiPolygon">

<rdfs:label xml:lang="en">Multi Polygon</rdfs:label>

<rdfs:subClassOf rdf:resource="http://www.opengis.net/ont/sf#MultiSurface"/>

www.episecc.eu

A MultiPolygon is a MultiSurface whose elements are Polygons.

The assertions for MultiPolygons are as follows.

a) The interiors of 2 Polygons that are elements of a MultiPolygon may not intersect.

b) The boundaries of any 2 Polygons that are elements of a MultiPolygon may not cross and may touch at only a finite number of Points.

c) A MultiPolygon is defined as topologically closed.

d) A MultiPolygon may not have cut lines, spikes or punctures, a MultiPolygon is a regular closed Point set,

e) The interior of a MultiPolygon with more than 1 Polygon is not connected; the number of connected components of the interior of a MultiPolygon is equal to the number of Polygons in the MultiPolygon.

The boundary of a MultiPolygon is a set of closed Curves (LineStrings) corresponding to the boundaries of its element Polygons. Each Curve in the boundary of the MultiPolygon is in the boundary of exactly 1 element Polygon, and every Curve in the boundary of an element Polygon is in the boundary of the MultiPolygon.

</rdfs:comment>


</owl:Class>



<owl:Class rdf:about="http://www.opengis.net/ont/sf#MultiSurface">

<rdfs:label xml:lang="en">Multi Surface</rdfs:label>



A MultiSurface is a 2-dimensional GeometryCollection whose elements are Surfaces, all using coordinates from the same coordinate reference system. The geometric interiors of any two Surfaces in a MultiSurface may not intersect in the full coordinate system. The boundaries of any two coplanar elements in a MultiSurface may intersect, at most, at a finite number of Points. If they were to meet along a curve, they could be merged into a single surface.

A MultiSurface may be used to represent heterogeneous surfaces collections of polygons and polyhedral surfaces. It defines a set of methods for its subclasses. The subclass of MultiSurface is MultiPolygon corresponding to a collection of Polygons only. Other collections shall use MultiSurface.

</rdfs:comment>


</owl:Class>



<owl:Class rdf:about="http://www.opengis.net/ont/sf#Point">

<rdfs:label xml:lang="en">Point</rdfs:label>



A Point is a 0-dimensional geometric object and represents a single location in coordinate space.

A Point has an x-coordinate value, a y-coordinate value. If called for by the associated Spatial Reference System, it may also have coordinate values for z and m.

The boundary of a Point is the empty set.

</rdfs:comment>


</owl:Class>

www.episecc.eu



<owl:Class rdf:about="http://www.opengis.net/ont/sf#Polygon">

<rdfs:label xml:lang="en">Polygon</rdfs:label>

<rdfs:subClassOf rdf:resource="http://www.opengis.net/ont/sf#Surface"/>


A Polygon is a planar Surface defined by 1 exterior boundary and 0 or more interior boundaries. Each interior boundary defines a hole in the Polygon.

The exterior boundary LinearRing defines the top of the surface which is the side of the surface from which the exterior boundary appears to traverse the boundary in a counter clockwise direction. The interior LinearRings will have the opposite orientation, and appear as clockwise when viewed from the top,

The assertions for Polygons (the rules that define valid Polygons) are as follows:

a) Polygons are topologically closed;

b) The boundary of a Polygon consists of a set of LinearRings that make up its exterior and interior boundaries;

c) No two Rings in the boundary cross and the Rings in the boundary of a Polygon may intersect at a Point but only as a tangent.

d) A Polygon may not have cut lines, spikes or punctures.

e) The interior of every Polygon is a connected point set;

f) The exterior of a Polygon with 1 or more holes is not connected. Each hole defines a connected component of the exterior.

</rdfs:comment>


</owl:Class>



<owl:Class rdf:about="http://www.opengis.net/ont/sf#PolyhedralSurface">

<rdfs:label xml:lang="en">Polyhedral Surface</rdfs:label>

<rdfs:subClassOf rdf:resource="http://www.opengis.net/ont/sf#Surface"/>


A PolyhedralSurface is a contiguous collection of polygons, which share common boundary segments. For each pair of polygons that touch, the common boundary shall be expressible as a finite collection of LineStrings. Each such LineString shall be part of the boundary of at most 2 Polygon patches.

For any two polygons that share a common boundary, the top of the polygon shall be consistent. This means that when two LinearRings from these two Polygons traverse the common boundary segment, they do so in opposite directions. Since the Polyhedral surface is contiguous, all polygons will be thus consistently oriented. This means that a non-oriented surface (such as Mbius band) shall not have single surface representations. They may be represented by a MultiSurface.

If each such LineString is the boundary of exactly 2 Polygon patches, then the PolyhedralSurface is a simple, closed polyhedron and is topologically isomorphic to the surface of a sphere. By the Jordan Surface Theorem (Jordans Theorem for 2-spheres), such polyhedrons enclose a solid topologically isomorphic to the interior of a sphere; the ball. In this case, the top of the surface will either point inward or outward of the enclosed finite solid. If outward, the surface is the exterior boundary of the enclosed surface. If inward, the surface is the interior of the infinite complement of the enclosed solid. A Ball with some number of voids (holes) inside can thus be presented as one exterior boundary shell, and some number in interior boundary shells.

</rdfs:comment>

www.episecc.eu


</owl:Class>



<owl:Class rdf:about="http://www.opengis.net/ont/sf#Surface">

<rdfs:label xml:lang="en">Surface</rdfs:label>



A Surface is a 2-dimensional geometric object.

A simple Surface may consists of a single patch that is associated with one exterior boundary and 0 or more interior boundaries. A single such Surface patch in 3-dimensional space is isometric to planar Surfaces, by a simple affine rotation matrix that rotates the patch onto the plane z = 0. If the patch is not vertical, the projection onto the same plane is an isomorphism, and can be represented as a linear transformation, i.e. an affine.

Polyhedral Surfaces are formed by stitching together such simple Surfaces patches along their common boundaries. Such polyhedral Surfaces in a 3-dimensional space may not be planar as a whole, depending on the orientation of their planar normals. If all the patches are in alignment (their normals are parallel), then the whole stitched polyhedral surface is co-planar and can be represented as a single patch if it is connected.

The boundary of a simple Surface is the set of closed Curves corresponding to its exterior and interior boundaries.

A Polygon is a simple Surface that is planar. A PolyhedralSurface is a simple surface, consisting of some number of Polygon patches or facets. If a PolyhedralSurface is closed, then it bounds a solid. A MultiSurface containing a set of closed PolyhedralSurfaces can be used to represent a Solid object with holes.

</rdfs:comment>


</owl:Class>



<owl:Class rdf:about="http://www.opengis.net/ont/sf#TIN">

<rdfs:label xml:lang="en">Triangulated Irregular Network</rdfs:label>

<rdfs:subClassOf rdf:resource="http://www.opengis.net/ont/sf#PolyhedralSurface"/>


A TIN (triangulated irregular network) is a PolyhedralSurface consisting only of Triangle patches.

</rdfs:comment>


</owl:Class>



<owl:Class rdf:about="http://www.opengis.net/ont/sf#Triangle">

<rdfs:label xml:lang="en">Triangle</rdfs:label>

<rdfs:subClassOf rdf:resource="http://www.opengis.net/ont/sf#Polygon"/>

www.episecc.eu


A Triangle is a polygon with 3 distinct, non-collinear vertices and no interior boundary.

</rdfs:comment>


</owl:Class>



<owl:Class rdf:about="http://www.w3.org/2006/time#DateTimeDescription">

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.w3.org/2006/time#day"/>

<owl:maxCardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:maxCardinality>

</owl:Restriction>

</rdfs:subClassOf>

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.w3.org/2006/time#dayOfYear"/>


</owl:Restriction>

</rdfs:subClassOf>

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.w3.org/2006/time#week"/>


</owl:Restriction>

</rdfs:subClassOf>

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.w3.org/2006/time#unitType"/>

<owl:cardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:cardinality>

</owl:Restriction>

</rdfs:subClassOf>

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.w3.org/2006/time#year"/>


</owl:Restriction>

</rdfs:subClassOf>

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.w3.org/2006/time#month"/>


</owl:Restriction>

</rdfs:subClassOf>

<rdfs:subClassOf>

<owl:Restriction>

www.episecc.eu

<owl:onProperty rdf:resource="http://www.w3.org/2006/time#minute"/>


</owl:Restriction>

</rdfs:subClassOf>

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.w3.org/2006/time#dayOfWeek"/>


</owl:Restriction>

</rdfs:subClassOf>

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.w3.org/2006/time#second"/>


</owl:Restriction>

</rdfs:subClassOf>

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.w3.org/2006/time#hour"/>


</owl:Restriction>

</rdfs:subClassOf>

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.w3.org/2006/time#timeZone"/>


</owl:Restriction>

</rdfs:subClassOf>

</owl:Class>



<owl:Class rdf:about="http://www.w3.org/2006/time#DateTimeInterval">

<rdfs:subClassOf rdf:resource="http://www.w3.org/2006/time#ProperInterval"/>

</owl:Class>



<owl:Class rdf:about="http://www.w3.org/2006/time#DayOfWeek">


<owl:Class>


<rdf:Description rdf:about="http://www.w3.org/2006/time#Wednesday"/>

<rdf:Description rdf:about="http://www.w3.org/2006/time#Friday"/>

<rdf:Description rdf:about="http://www.w3.org/2006/time#Saturday"/>

www.episecc.eu

<rdf:Description rdf:about="http://www.w3.org/2006/time#Tuesday"/>

<rdf:Description rdf:about="http://www.w3.org/2006/time#Monday"/>

<rdf:Description rdf:about="http://www.w3.org/2006/time#Sunday"/>

<rdf:Description rdf:about="http://www.w3.org/2006/time#Thursday"/>

</owl:oneOf>

</owl:Class>


</owl:Class>



<owl:Class rdf:about="http://www.w3.org/2006/time#DurationDescription">

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.w3.org/2006/time#weeks"/>


</owl:Restriction>

</rdfs:subClassOf>

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.w3.org/2006/time#days"/>


</owl:Restriction>

</rdfs:subClassOf>

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.w3.org/2006/time#years"/>


</owl:Restriction>

</rdfs:subClassOf>

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.w3.org/2006/time#months"/>


</owl:Restriction>

</rdfs:subClassOf>

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.w3.org/2006/time#hours"/>


</owl:Restriction>

</rdfs:subClassOf>

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.w3.org/2006/time#minutes"/>


</owl:Restriction>

www.episecc.eu

</rdfs:subClassOf>

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.w3.org/2006/time#seconds"/>


</owl:Restriction>

</rdfs:subClassOf>

</owl:Class>



<owl:Class rdf:about="http://www.w3.org/2006/time#Instant">

<rdfs:subClassOf rdf:resource="http://www.w3.org/2006/time#TemporalEntity"/>

<owl:disjointWith rdf:resource="http://www.w3.org/2006/time#ProperInterval"/>

</owl:Class>



<owl:Class rdf:about="http://www.w3.org/2006/time#Interval">

<rdfs:subClassOf rdf:resource="http://www.w3.org/2006/time#TemporalEntity"/>

</owl:Class>



<owl:Class rdf:about="http://www.w3.org/2006/time#January">

<rdfs:subClassOf rdf:resource="http://www.w3.org/2006/time#DateTimeDescription"/>

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.w3.org/2006/time#unitType"/>

<owl:hasValue rdf:resource="http://www.w3.org/2006/time#unitMonth"/>

</owl:Restriction>

</rdfs:subClassOf>

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.w3.org/2006/time#month"/>

<owl:hasValue rdf:datatype="&xsd;gMonth">--01</owl:hasValue>

</owl:Restriction>

</rdfs:subClassOf>

</owl:Class>

www.episecc.eu

<owl:Class rdf:about="http://www.w3.org/2006/time#ProperInterval">

<rdfs:subClassOf rdf:resource="http://www.w3.org/2006/time#Interval"/>

</owl:Class>



<owl:Class rdf:about="http://www.w3.org/2006/time#TemporalEntity">


<owl:Class>

<owl:unionOf rdf:parseType="Collection">

<rdf:Description rdf:about="http://www.w3.org/2006/time#Instant"/>

<rdf:Description rdf:about="http://www.w3.org/2006/time#Interval"/>

</owl:unionOf>

</owl:Class>


</owl:Class>



<owl:Class rdf:about="http://www.w3.org/2006/time#TemporalUnit">


<owl:Class>


<rdf:Description rdf:about="http://www.w3.org/2006/time#unitMonth"/>

<rdf:Description rdf:about="http://www.w3.org/2006/time#unitMinute"/>

<rdf:Description rdf:about="http://www.w3.org/2006/time#unitDay"/>

<rdf:Description rdf:about="http://www.w3.org/2006/time#unitHour"/>

<rdf:Description rdf:about="http://www.w3.org/2006/time#unitYear"/>

<rdf:Description rdf:about="http://www.w3.org/2006/time#unitSecond"/>

<rdf:Description rdf:about="http://www.w3.org/2006/time#unitWeek"/>

</owl:oneOf>

</owl:Class>


</owl:Class>



<owl:Class rdf:about="http://www.w3.org/2006/time#Year">

<rdfs:subClassOf rdf:resource="http://www.w3.org/2006/time#DurationDescription"/>

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.w3.org/2006/time#years"/>

www.episecc.eu


</owl:Restriction>

</rdfs:subClassOf>

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.w3.org/2006/time#seconds"/>


</owl:Restriction>

</rdfs:subClassOf>

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.w3.org/2006/time#minutes"/>


</owl:Restriction>

</rdfs:subClassOf>

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.w3.org/2006/time#hours"/>


</owl:Restriction>

</rdfs:subClassOf>

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.w3.org/2006/time#weeks"/>


</owl:Restriction>

</rdfs:subClassOf>

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.w3.org/2006/time#months"/>


</owl:Restriction>

</rdfs:subClassOf>

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="http://www.w3.org/2006/time#days"/>


</owl:Restriction>

</rdfs:subClassOf>

</owl:Class>



<owl:Class rdf:about="http://www.w3.org/2006/timezone#TimeZone"/>

www.episecc.eu




<owl:NamedIndividual rdf:about="http://www.episecc.eu/sem_rep#epi00284">

<rdf:type rdf:resource="http://webprotege.stanford.edu/epi00238"/>

<rdfs:label xml:lang="en">highPriority</rdfs:label>

</owl:NamedIndividual>




<rdfs:label xml:lang="en">mediumPriority</rdfs:label>





<rdfs:label xml:lang="en">lowPriority</rdfs:label>





<rdfs:label xml:lang="en">available</rdfs:label>

www.episecc.eu



<rdfs:label xml:lang="en">needed</rdfs:label>





<rdfs:label xml:lang="en">inUse</rdfs:label>




<owl:NamedIndividual rdf:about="http://www.w3.org/2006/time#Friday">

<rdf:type rdf:resource="http://www.w3.org/2006/time#DayOfWeek"/>




<owl:NamedIndividual rdf:about="http://www.w3.org/2006/time#Monday">





<owl:NamedIndividual rdf:about="http://www.w3.org/2006/time#Saturday">





<owl:NamedIndividual rdf:about="http://www.w3.org/2006/time#Sunday">

www.episecc.eu

<owl:NamedIndividual rdf:about="http://www.w3.org/2006/time#Thursday">





<owl:NamedIndividual rdf:about="http://www.w3.org/2006/time#Tuesday">





<owl:NamedIndividual rdf:about="http://www.w3.org/2006/time#Wednesday">





<owl:NamedIndividual rdf:about="http://www.w3.org/2006/time#unitDay">

<rdf:type rdf:resource="http://www.w3.org/2006/time#TemporalUnit"/>




<owl:NamedIndividual rdf:about="http://www.w3.org/2006/time#unitHour">





<owl:NamedIndividual rdf:about="http://www.w3.org/2006/time#unitMinute">

www.episecc.eu

<owl:NamedIndividual rdf:about="http://www.w3.org/2006/time#unitMonth">





<owl:NamedIndividual rdf:about="http://www.w3.org/2006/time#unitSecond">





<owl:NamedIndividual rdf:about="http://www.w3.org/2006/time#unitWeek">





<owl:NamedIndividual rdf:about="http://www.w3.org/2006/time#unitYear">





<rdf:Description rdf:about="&dc;format">

<rdfs:label xml:lang="en">Format</rdfs:label>




<terms:description xml:lang="en">Examples of dimensions include size and duration. Recommended best practice is to use a controlled vocabulary such as the list of Internet Media Types [MIME].</terms:description>

<rdfs:comment xml:lang="en">The file format, physical medium, or dimensions of the resource.</rdfs:comment>


www.episecc.eu

<terms:hasVersion rdf:resource="http://dublincore.org/usage/terms/history/#format-007"/>


</rdf:Description>

<rdf:Description rdf:about="http://webprotege.stanford.edu/R83P4JouJUgJLAwUM6Xa038">

<rdfs:label>Technical</rdfs:label>

</rdf:Description>

<rdf:Description rdf:about="&dc;identifier">

<rdfs:label xml:lang="en">Identifier</rdfs:label>




<rdfs:comment xml:lang="en">An unambiguous reference to the resource within a given context.</rdfs:comment>

<terms:description xml:lang="en">Recommended best practice is to identify the resource by means of a string conforming to a formal identification system. </terms:description>

<terms:hasVersion rdf:resource="http://dublincore.org/usage/terms/history/#identifier-006"/>


</rdf:Description>

<rdf:Description rdf:about="&dc;language">

<rdfs:label xml:lang="en">Language</rdfs:label>



<rdfs:comment xml:lang="en">A language of the resource.</rdfs:comment>


<terms:description xml:lang="en">Recommended best practice is to use a controlled vocabulary such as RFC 4646 [RFC4646].</terms:description>

<terms:hasVersion rdf:resource="http://dublincore.org/usage/terms/history/#language-007"/>


<rdfs:seeAlso rdf:resource="http://www.ietf.org/rfc/rfc4646.txt"/>

</rdf:Description>

<rdf:Description rdf:about="http://purl.org/dc/elements/1.1/">


<terms:title xml:lang="en">Dublin Core Metadata Element Set, Version 1.1</terms:title>

<terms:publisher rdf:resource="http://purl.org/dc/aboutdcmi#DCMI"/>

</rdf:Description>

<rdf:Description rdf:about="http://webprotege.stanford.edu/RCbkhZo4mGnGFMEO6QVyyg9">

<rdfs:label>Origin (facet)</rdfs:label>

</rdf:Description>

<rdf:Description rdf:about="http://webprotege.stanford.edu/R79bDRUdEvA13kvw0mlpQd9">

<rdfs:label>Origin</rdfs:label>

</rdf:Description>

<rdf:Description rdf:about="http://webprotege.stanford.edu/R7ONPXEGPWJuUhBlpqwMlYA">

<rdfs:label>TypeD</rdfs:label>

</rdf:Description>

<rdf:Description rdf:about="&dc;publisher">

<rdfs:label xml:lang="en">Publisher</rdfs:label>



www.episecc.eu




<rdfs:comment xml:lang="en">An entity responsible for making the resource available.</rdfs:comment>

<terms:description xml:lang="en">Examples of a Publisher include a person, an organization, or a service. Typically, the name of a Publisher should be used to indicate the entity.</terms:description>

<terms:hasVersion rdf:resource="http://dublincore.org/usage/terms/history/#publisher-006"/>


</rdf:Description>

<rdf:Description rdf:about="http://webprotege.stanford.edu/R8XXkbXzb6a9woas5nv62Tt">

<rdfs:label>Technical</rdfs:label>

</rdf:Description>

<rdf:Description rdf:about="&dc;source">

<rdfs:label xml:lang="en">Source</rdfs:label>



<rdfs:comment xml:lang="en">A related resource from which the described resource is derived.</rdfs:comment>


<terms:description xml:lang="en">The described resource may be derived from the related resource in whole or in part. Recommended best practice is to identify the related resource by means of a string conforming to a formal identification system.</terms:description>

<terms:hasVersion rdf:resource="http://dublincore.org/usage/terms/history/#source-006"/>


</rdf:Description>

<rdf:Description rdf:about="&dc;rights">

<rdfs:label xml:lang="en">Rights</rdfs:label>




<rdfs:comment xml:lang="en">Information about rights held in and over the resource.</rdfs:comment>

<terms:description xml:lang="en">Typically, rights information includes a statement about various property rights associated with the resource, including intellectual property rights.</terms:description>

<terms:hasVersion rdf:resource="http://dublincore.org/usage/terms/history/#rights-006"/>


</rdf:Description>

<rdf:Description rdf:about="&dc;coverage">

<rdfs:label xml:lang="en">Coverage</rdfs:label>




<terms:description xml:lang="en">Spatial topic and spatial applicability may be a named place or a



www.episecc.eu

location specified by its geographic coordinates. Temporal topic may be a named period, date, or date range. A jurisdiction may be a named administrative entity or a geographic place to which the resource applies. Recommended best practice is to use a controlled vocabulary such as the Thesaurus of Geographic Names [TGN]. Where appropriate, named places or time periods can be used in preference to numeric identifiers such as sets of coordinates or date ranges.</terms:description>

<rdfs:comment xml:lang="en">The spatial or temporal topic of the resource, the spatial applicability of the resource, or the jurisdiction under which the resource is relevant.</rdfs:comment>

<terms:hasVersion rdf:resource="http://dublincore.org/usage/terms/history/#coverage-006"/>


</rdf:Description>

<rdf:Description rdf:about="http://webprotege.stanford.edu/RpTdZlMiAnySw7qiqPMZoX">

<rdfs:label>Humans and nature</rdfs:label>

<rdfs:comment>A disaster originates from ether forces of nature or human activities.</rdfs:comment>

</rdf:Description>

<rdf:Description rdf:about="&dc;subject">

<rdfs:label xml:lang="en">Subject</rdfs:label>




<rdfs:comment xml:lang="en">The topic of the resource.</rdfs:comment>

<terms:description xml:lang="en">Typically, the subject will be represented using keywords, key phrases, or classification codes. Recommended best practice is to use a controlled vocabulary.</terms:description>

<terms:hasVersion rdf:resource="http://dublincore.org/usage/terms/history/#subject-007"/>


</rdf:Description>

<rdf:Description rdf:about="&dc;type">

<rdfs:label xml:lang="en">Type</rdfs:label>




<terms:description xml:lang="en">Recommended best practice is to use a controlled vocabulary such as the DCMI Type Vocabulary [DCMITYPE]. To describe the file format, physical medium, or dimensions of the resource, use the Format element.</terms:description>

<rdfs:comment xml:lang="en">The nature or genre of the resource.</rdfs:comment>

<terms:hasVersion rdf:resource="http://dublincore.org/usage/terms/history/#type-006"/>


</rdf:Description>

<rdf:Description rdf:about="&dc;relation">

<rdfs:label xml:lang="en">Relation</rdfs:label>



<rdfs:comment xml:lang="en">A related resource.</rdfs:comment>


<terms:description xml:lang="en">Recommended best practice is to identify the related resource by


www.episecc.eu

means of a string conforming to a formal identification system. </terms:description>

<terms:hasVersion rdf:resource="http://dublincore.org/usage/terms/history/#relation-006"/>


</rdf:Description>

<rdf:Description rdf:about="&dc;title">

<rdfs:label xml:lang="en">Title</rdfs:label>



<rdfs:comment xml:lang="en">A name given to the resource.</rdfs:comment>


<terms:hasVersion rdf:resource="http://dublincore.org/usage/terms/history/#title-006"/>


</rdf:Description>

</rdf:RDF>

D4.5. - Taxonomy: Lessons learned 5_Deliverable... · standard (SKOS-thes) have been compared to...

Documents

Transcript of D4.5. - Taxonomy: Lessons learned 5_Deliverable... · standard (SKOS-thes) have been compared to...