d4.3. data model - episecc · developed. using unified modelling language (uml) use case diagram,...

EPISECC_WP4_D4 3_Deliverable_Report.docx 91 |1

www.episecc.eu

D4.3. – Data model

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

Date of project start: 2014-06-01 Date of submission: 2016-05-10

Duration of project: 36 months Deliverable approved by: HWC

PSCE

Lead Beneficiary: HITEC

Contributing Beneficiaries: UNIST, IES, AIT, FRQ

Establish Pan-European Information Space to Enhance seCurity of Citizens

http://www.episecc.eu/


www.episecc.eu

Executive Summary

The deliverable provides detailed description of the data model for the EPISECC Semantic Repository

including methodology, requirements, design and testing. The methodology explains the design steps

and formal languages and tools used for the development of Resource Description Framework (RDF)

databases. The methodology is based on the principles of information system development where

database is one of the phases. The main phases are outlined and sources of information for data

model requirements are identified. The sources of information for database requirements are:

EPISECC Taxonomy structure, Common Information Space (CIS), and data models used by

information tools analysed in Deliverable 2.2. Since the data base is a part of CIS sub-system

Semantic Mapping, semantic mapping and matching processes are defined and analysed in the

context of CIS.

Based on the identified processes, a draft design of CIS sub-system Semantic Mapping was

developed. Using Unified Modelling Language (UML) Use case diagram, five use cases used by two

actors are recognised: enter semantics, enter semantic mapping, request semantic matching, create

compound terms and infer semantic relations. Some examples of the semantic mapping and

matching processes are given as well.

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.

Simple Knowledge Organisation System – thesaurus (SKOS-thes) is selected as the most suitable

design pattern for the EPISECC Semantic Repository. The representation of the repository’s elements

in SKOS-thes model is defined and described. To semantically relate concepts from organisations to

the EPISECC Taxonomy and other semantic sub-structures, the more subtle way of relating is needed

other then 1:1 translation, so SKOS-thes model includes five semantic relations as five object

properties.

This deliverable describes the first implementation and testing of data model done in parallel with

the data model design. A test database was created and loaded with data and semantic mapping

between concepts of different sub-structures were also inserted. Data model testing includes: testing

of logical consistency by applying reasoning algorithms and testing of semantic matching by applying

reasoning algorithms and SPARQL queries. The test database was created with Protégé Desktop

software already used for the EPISECC Taxonomy development. The database is stored as an

Ontology Web Language (OWL) file in RDF/XML syntax. The second implementation and testing will

be done through the proof of concept and validation. Results will be elaborated in the Deliverable

6.3. The final data model will be elaborated in Task 4.5 “Lessons learned from proof of concept and

validation” and delivered in the Deliverable 4.5.

The SKOS-thes data model and an excerpt of the test database are given as RDF files in the Annex.



www.episecc.eu

Table of Content

List of Tables ............................................................................................................................................ 5

List of Figures ........................................................................................................................................... 6

List of Acronyms ...................................................................................................................................... 7

List of Terms ............................................................................................................................................ 9

1. Introduction ................................................................................................................................... 10

2. Methodology ................................................................................................................................. 12

2.1. Information system and database development methodology – the EPISECC approach ..... 12

2.2. RDF database design .............................................................................................................. 14

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

3. Data model requirements ............................................................................................................. 17

3.1. Common Information Space and Data model’s objectives ................................................... 17

3.2. Study of data models used by information tools ................................................................... 18

3.3. The EPISECC Taxonomy structure .......................................................................................... 23

3.4. Common Information Space design ....................................................................................... 24

3.4.1. Semantic interoperability processes ............................................................................. 26

3.4.2. Draft design of CIS sub-system Semantic Mapping ....................................................... 27

3.4.3. Draft design of semantic mapping and matching processes ......................................... 29

3.4.4. Example for semantic matching .................................................................................... 30

4. Data model design ......................................................................................................................... 35

4.1. The EPISECC project Semantic Repository ............................................................................. 35

4.2. State-of-the-art for the semantic interoperability ................................................................ 37

4.2.1. RDF data model ............................................................................................................. 38

4.2.2. Semantic web architecture ........................................................................................... 40

4.3. The Semantic Repository Data model.................................................................................... 41

4.3.1. The SKOS-thes design pattern ....................................................................................... 42

4.3.2. Introduction of SKOS-thes to the EPISECC project ........................................................ 48

4.3.2.1. Sub-structures elements in SKOS-thes .......................................................................... 48

4.3.2.2. Semantic relations in SKOS-thes .................................................................................... 51

5. Data model testing ........................................................................................................................ 54



www.episecc.eu

5.1. Implementation in Protégé Desktop ...................................................................................... 54

5.2. Testing of semantic mapping and matching by reasoning and use of SPARQL ..................... 57

6. Conclusions and follow-up suggestions ........................................................................................ 61

Bibliography ........................................................................................................................................... 62

Annex ..................................................................................................................................................... 65

I. SKOS-thes data model ................................................................................................................... 65

II. An excerpt of the test database .................................................................................................... 80



www.episecc.eu

List of Tables

Table 1: Standards and guidelines used by organisations (Deliverable 4.1) ......................................... 19

Table 2: Data models used by tools and corresponding Data model requirements ............................. 22

Table 3: Semantic matching rules ......................................................................................................... 33

Table 4: Triples of the EPISECC Taxonomy stored in RDF data model .................................................. 39

Table 5: SKOS models ............................................................................................................................ 43

Table 6: Representation of the sub-structures elements in SKOS-thes model ..................................... 49

Table 7: Representation of the CIS semantic mapping in SKOS-thes model ......................................... 52



www.episecc.eu

List of Figures

Figure 1: Sources of information for the EPISECC Data model requirements ...................................... 14

Figure 2: Two-step approach in RDF database development ............................................................... 15

Figure 3: UML class diagram of EMSI messages standard [18] ............................................................. 21

Figure 4: Various semantic structures to be stored by the Data model ............................................... 23

Figure 5: Tools interfaces without CIS (a) and with CIS (b) ................................................................... 25

Figure 6: The role of the taxonomy in CIS (Deliverable 4.2).................................................................. 25

Figure 7: UML Use case diagram of CIS sub-system Semantic Mapping............................................... 28

Figure 8: Process of semantic matching by use of Semantic Mapping Services of CIS ......................... 31

Figure 9: Example of information sent in CAP format ........................................................................... 32

Figure 10: Content of the Semantic Repository .................................................................................... 36

Figure 11: Semantic Web technology layer stack [24] .......................................................................... 37

Figure 12: RDF Triple ............................................................................................................................. 38

Figure 13: Architecture of Knowledge base [27] ................................................................................... 40

Figure 14: Semantic web application architecture (adopted from [15]) .............................................. 41

Figure 15: The Semantic Repository architecture ................................................................................. 41

Figure 16: SKOS-thes directed graph: classes and properties ............................................................... 45

Figure 17: SKOS-thes object, annotation and data properties .............................................................. 47

Figure 18: Graph of the SKOS-thes semantic relations (adopted from [15]) ........................................ 51

Figure 19: Semantic mapping with SKOS-thes relations ....................................................................... 53

Figure 20: The EPISECC Taxonomy concepts in the test database ........................................................ 54

Figure 21: The EPISECC Taxonomy facets in the test database............................................................. 55

Figure 22: Protégé Desktop interface with individuals listed by identifiers ......................................... 56

Figure 23: Protégé Desktop interface with individuals listed by labels ................................................ 56

Figure 24: Concepts from three sub-structures and with multilingual labels in the test database ...... 57

Figure 25: Semantic mappings entered in the test database................................................................ 58

Figure 26: Inserted and inferred relations in the test database ........................................................... 58

Figure 27: Semantic matching process .................................................................................................. 59

Figure 28: Exact match between EMSI and CRO_SOP concepts ........................................................... 60

Figure 29: Broad match between EMSI and CRO_SOP concepts .......................................................... 60



www.episecc.eu

List of Acronyms

Abbreviation Description

ABox Assertion Box

ANSI American National Standards Institute

API Application Programming Interface

CAP Common Alerting Protocol

CECIS Common Emergency Communication and Information System

CEN European Committee for Standardization / Comité Européen De Normalisation

CIS Common Information Space

CWA CEN Workshop Agreement

EC/ERCC European Commission / Emergency Response Coordination Centre

EMSI Emergency Management Shared Information

ER Entity-relationship

EU European Union

GeoSPARQL A Geographic Query Language for RDF Data

GSM Global System for Mobile Communication

HTML Hyper Text Markup Language

HTTP HyperText Transfer Protocol

INSPIRE Infrastructure for Spatial Information in the European Community

IP Internet Protocol

ISO International Organisation for Standardization

ISO/TR International Organisation for Standardization / Technical Report

KOS Knowledge Organisation System

NISO National Information Standards Organisation

OSOCC On-Site Operations Coordination Centre

OWL Ontology Web Language

PPDR Public Protection and Disaster Relief



www.episecc.eu

QUDT Quantities, Units, Dimensions and Types

RDF Resource Description Framework

RDFS Resource Description Framework Schema

REST REpresentational State Transfer

RIF Rule Interchange Format

SKOS Simple Knowledge Organisation System

SKOS-XL SKOS eXtension for Labels

SKOS-thes SKOS extension for thesauri

SOAP Simple Object Access Protocol

SOP Standard Operating Procedure

SPARQL SPARQL Protocol and RDF Query Language

SWEET Semantic Web for Earth and Environmental Terminology

TBox Terminology Box

TDB Triple Database

TETRA Terrestrial Trunked Radio

TSO/CWA Tactical Situation Object

UML Unified Modelling Language

UN/OCHA United Nations / Office for the Coordination of Humanitarian Affairs

URI Uniform Resource Identifier

TSO Tactical Situation Object

W3C World Wide Web Consortium

XML Extensible Markup Language



www.episecc.eu

List of Terms

Term Definition

Compound term Real object can be classified using a compound term, which is a set of terms from one or several facets (D4.2).

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

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

Knowledge base The underlying set of facts, assumptions, and rules which a computer system has available to solve a problem (Oxford dictionary).

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

Predicate calculus The branch of symbolic logic that deals with propositions containing predicates, names, and quantifiers (Oxford dictionary).

Resource Description Framework (RDF) data model

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

Resource Description Framework Scheme (RDFS)

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

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

Semantic web Semantic web is W3C’s vision of the web of linked data. Semantic web technologies enable people to create data stores on the web, build vocabularies, and write rules for handling data. Linked data are empowered by technologies such as RDF, SPARQL, OWL, and SKOS (W3C).

Simple Knowledge Organisation System (SKOS)

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

SPARQL query language A query language for RDF.

Taxonomy A scheme of classification (Oxford dictionary).

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

Triple store A database for the storage of RDF data or triples. A triple is a statement composed of subject-predicate-object.



www.episecc.eu

1. Introduction

Following the work on the taxonomy described in deliverable D4.2, forms the basis for semantic

interoperability of the Common Information Space. The data model needs to be developed, for which

this document explains. The analysis of the CIS capabilities and end user’s needs resulted in the idea

of the data model as a definition not only for the EPISECC Taxonomy but also for more complex

semantics. Consequently, the idea of storing both semantic structures and accompanied knowledge

emerged as the most suitable solution. The search for the adequate data model revealed that

predicate calculus based structures are capable to fulfil the requirements. Recent efforts in the web-

based solutions use triple store or RDF store to define aspects of the semantic web. There are a

number of robust metadata and ontology standards developed by the W3C community using RDF [1]

and OWL standards [2] where the database schema describing data semantics can be distributed

together with data enabling semantic interoperability [3].

The EPISECC Semantic Repository will be loaded with concepts and their relations from different

structures. The EPISECC Taxonomy, which is a specific purpose one, will be coupled with selected and

adjusted generic concepts from existing ontologies and vocabularies as follows:

GeoSPARQL vocabulary [4],

W3C Time ontology model [5],

SWEET ontology [6],

QUDT ontology [7].

Concepts from CAP XML schema [8] and EMSI data model [9] including selected parts of EMSI codes,

as well as first responders’ concepts and structures will be stored in the repository.

During the classification process organisations’ concepts will be mapped to the best possible

matching concepts in the EPISECC Taxonomy. In order to obtain the best possible prerequisites for

the semantic interoperability, the classification process should be controlled and users should be

guided to find either the exact match or the lowest generic concept. This report delivers the data

model and guidelines. How to develop an adequate user interface will be elaborated in the

Deliverable 4.5 “Lessons learned from proof of concept and validation”, after testing of the whole

concept with end users.

Comparing to the structures that could be found in the literature or shared through the web, the

EPISECC Semantic Repository (hereinafter also referred to as the Semantic Repository) has a specific

function of classification which is defined as follows. The Semantic Repository’s data model follows

the purpose of the EPISECC project and is designed to perform the following functions:

to perform classification of first responders’ concepts against EPISECC Taxonomy,

to infer and retrieve relations between first responders’ concepts,

to implement semantic web functionalities where feasible.

This deliverable is structured in six chapters. Following this introduction, the second chapter deals

with the methodology for the data model development, including the procedures and principles. The



www.episecc.eu

methodology defines the data model design approach, RDF database design, formal languages and

tools.

The third chapter brings information for the data model requirements. The results from the previous

deliverables dealing with the analysis of the EPISECC Inventory and data models which are used by

the information tools commonly used in PPDR, are summarised and elaborated. The major

requirements come from the EPISECC Taxonomy structure and CIS semantic interoperability. The

perspectives of the CIS, namely requirements of the interoperability components, are studied and

put into relation with the data model concept.

The fourth chapter is dedicated to the development of the data model. It delivers in detail the role,

structure and model for the Semantic Repository. The Semantic web architecture, which is the basis

for the data model, is explained and the state-of-the-art in semantic interoperability is elaborated.

This chapter gives a detailed explanation on the SKOS-thes model [10], which is selected as the most

suitable one for the purpose of the Semantic Repository. A detailed description of the relationship

between CIS semantic mapping processes and SKOS-thes model is provided as well.

The fifth chapter deals with the data model testing. The logical consistency of the database is tested

by applying reasoning algorithms and semantic matching. The detailed structure of the data model

and an excerpt of the test database are given in the Annexes.

The report ends with a discussion about the data model design and follow-up suggestions,

particularly for the application of EPISECC Semantic Repository in the proof of concept phase.



www.episecc.eu

2. Methodology

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

approach corresponds to a database development methodology [11] including development phases

such as system analysis and requirements definition, database design, implementation, testing and

maintenance. Additional topics are elaborated during the data model development according to the

research nature of the EPISECC project and tasks defined by the project proposal. The elaborated

topics include the following:

the results from other EPISECC project’s tasks,

the EPISECC Taxonomy (Deliverable 4.2) which represents the backbone for the data model.

database design, which follows a specific approach for the Resource Description Framework

(RDF) data model,

the database schema, which is written in Resource Description Framework Schema (RDFS)

and Ontology Web Language (OWL),

the open source tool Protégé, which is chosen for data model development,

the open source tool Apache Jena, which is chosen as database management system.

the implementation and testing are carried out in two steps: the first step is carried out in

parallel with database design and the second step will be done along with CIS functions

design and validation through the proof of concept,

the final data model will be elaborated in Task 4.5 “Lessons learned from proof of concept

and validation” and delivered in the Deliverable 4.5.

the database maintenance is not foreseen during the project lifetime.

Forthcoming sections describe the applied methodology in detail.

2.1. Information system and database development methodology – the EPISECC approach

The development of our data model follows the methodology of information system development.

The data model describes structure and content of a database, a constituent part of an information

system.

There are several information system frameworks based on the standard development methodology.

Some of the most known are Waterfall, Prototyping, Incremental, Spiral and Rapid Application

Development methodology [12]. All of them include the work phases of system analysis and

requirements definition, system design, system development, installation, testing, operations and

maintenance. Database development is one phase of information system development. The main

database development phases are:

system analysis and definition of database requirements,

database design,

database implementation,

database testing,



www.episecc.eu

database maintenance.

System analysis involves braking down the system into elements like sub-systems and procedures,

analysing system’s goals and defining what parts of the system need to be modelled. The end users

are engaged by interviews or by questionnaires and the process ends up with a description of

requirements for the system. Herein, the system analysis is applied to data modelling resulting in

description of requirements for a database.

According to the data model levels defined by ANSI standard [13], database design consists of three

phases: conceptual, logical and physical data model design. Conceptual data model design is based

on data requirements for the applications being developed. It consists of entity classes, attributes

and relationships. The logical data model depends on the selected database model e.g. relational,

object-oriented etc. It describes logical elements of the model like tables and columns for relational

database, object-oriented classes for object-oriented database and in a similar manner for other

models. The physical data model translates the logical data model into a database structure and

includes definition of tables and columns for relational database, primary and foreign keys for tables,

constraints for columns, indexing of tables, and other sub-structures.

Database implementation includes the following:

selection of a database management system such as Oracle, Postgres, MySQL etc,

installation of database management system on a server,

creation of empty database structure,

data conversion and loading.

Database testing deals with finding errors in a database and includes experimental work with a

database as well as compliance checking of requirements. The most important data transactions are

monitored and their performances are measured.

Database maintenance includes observing the performance of a database management system as

well as its maintaining and upgrading when new requirements arise.

The development of the EPISECC Data model follows the above described database development

methodology. Considering the research nature of the EPISECC project and definitions included in the

project proposal, there are some project’s specific details which influence the application of the

methodology. The following paragraph outlines the EPISECC approach for the development of the

data model and database.

To develop the EPISECC Data model requirements, the results of other EPISECC project’s tasks are

being used and further studied (see Figure 1). The data model requirements are described in Chapter

3.



www.episecc.eu

Figure 1: Sources of information for the EPISECC Data model requirements

The database design follows a specific approach for the Resource Description Framework (RDF) data

model and is based on reusing existing models of domain knowledge explained in the Section 2.2.

Database implementation and testing are carried out in two steps. The first implementation and

testing is done in parallel with database design and is described in Chapter 5. The second

implementation and testing will be done along with CIS functions design and validation through the

Proof of concept (Tasks 6.1, 6.2 and 6.3). The RDF database testing is based on the development of

test use cases and competency questions the model should answer. The final Data model will be

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

Deliverable 4.5.

2.2. RDF database design

Our data model is based on the RDF data model which is intended for managing distributed data

across the World Wide Web [1]. The rationale for selecting the RDF data model is described in

Chapter 3 and Chapter 4. Herein, the specifics of RDF database development are shortly presented.

While most of the relational databases are developed from scratch, the RDF databases reuse already

developed models also called design patterns. Therefore, the first step is to search for a data model

which suits the project’s needs and then to introduce and take reference from it in our system.

Conceptual modelling consists of the definition of classes, their properties and axioms. Logical

modelling checks the logical consistency and integrity of the model by use of reasoning algorithms.

Physical modelling corresponds to the physical modelling of the relational model because the RDF

databases are implemented in relational database management systems.

There are several recently developed methodologies for the RDF database development:

Methontology, On-To-Knowledge, Diligent and NeOn Methodology [14]. The whole process can be

summarised in two main steps shown in Figure 2.

•Studying the EPISECC project proposal Common Information Space objectives

• Studying the EPISECC deliverables 2.1 and 2.2 Analysis of the currently used information tools

•Studying the EPISECC deliverables 3.4 and 4.1 Analysis of informational interoperability

•Studying the EPISECC deliverable 4.2 EPISECC Taxonomy

•Studying the EPISECC draft deliverable 5.4 Draft CIS architecture



www.episecc.eu

Figure 2: Two-step approach in RDF database development

In the first step, an expert models the domain knowledge: define basic concepts and relations among

them; define axioms and rules for data interpretation and reasoning. In the EPISECC project, the

domain knowledge is described in the project deliverables as shown in Figure 1. The key source of

domain knowledge is the EPISECC Taxonomy (Deliverable 4.2) which represents the backbone for the

data model.

The second step is to search for already developed models which could be reused and to introduce

them into the system. Moreover, the data could be linked to upper ontology models or similar

structures, enabling other applications to reuse it.

Once the RDF data model is developed, the RDF database could be created and loaded with data.

The final step is to test the developed RDF database. Logical consistency of the RDF database is

checked by applying reasoning algorithms. The model is not consistent if reasoning algorithms infer

that one individual belongs to two disjoint classes. Data modelling is subjective work of an expert and

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

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

[15].

2.3. Formal languages and tools

The description of the database structure in a formal language is named ‘database schema’.

Resource Description Framework Schema (RDFS) and Ontology Web Language (OWL) are the basic

languages for RDF databases and they are selected for the EPISECC Data model. RDFS and OWL are

based on RDF vocabulary that defines Subject, Predicate and Object, which constitute Triples, the

building blocks in RDF database [15].

There is a key difference between RDFS and OWL and other formal languages. RDFS and OWL have

the same structure as an RDF database and they are stored in a database together with data. This is

not the case with entity–relationship model (ER) diagrams describing relational databases or with

UML diagrams describing object-oriented databases. Via RDFS and OWL, the database schema

describing data semantics can be distributed together with the data. It brings a significant benefit in

using data distributed over the World Wide Web because it enables semantic interoperability.

The RDFS language has a small set of constructs and rules [1].

DOMAIN KNOWLEDGE

REUSED

MODELS RDF data model



www.episecc.eu

The constructs are the following:

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

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

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

Even with such a small number of constructs, RDFS is very effective in integrating data.

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

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

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

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

constructs, which are specifications of the World Wide Web Consortium (W3C), can be used to

model complex relationships between classes, properties and individuals.

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

and for database implementation. The Protégé Desktop tool is selected for data model development

[16], because it supports RDFS and OWL languages and includes reasoning algorithms used for data

model consistency checking as well as SPARQL query language used for database testing. Protégé

Desktop is described in detail in the deliverable D4.2 Taxonomy model.

Apache Jena [17] is selected as database management system for RDF database also called triple

store. Apache Jena supports several relational databases (open source and commercial) for

persistent store of triples. It includes an inference Application Programming Interface (API), RDF API

and Fuseki (a SPARQL end-point accessible over HTTP).



www.episecc.eu

3. Data model requirements

Data model requirements are developed along with on-going development of the CIS architecture

and CIS functions. The main documents being studied are the following EPISECC project deliverables:

the EPISECC project proposal,

Deliverable 2.1 PPDR Information Space: Document “PPDR Information Space” - Status quo

of commercial, research and governmental projects and applications,

Deliverable 2.2 Dealing with natural or man-made crisis and disaster: Document “Dealing

with natural or man-made crisis and disaster” - Standards, management approaches and

good practices in information provision and exchange,

Deliverable 3.4 Pan-European inventory of events/disasters including business models,

Deliverable 4.1 Evaluation of the Inventory – Report,

Deliverable 4.2 Taxonomy model ‐ Document with detailed description of the taxonomy

structure,

draft of Deliverable 5.4 Architecture of the Common Information Space.

The results of the undertaken analysis and data model requirements are described in the following

paragraphs.

3.1. Common Information Space and Data model’s objectives

The EPISECC project proposal has defined that Common Information Space should include

appropriate semantic definitions by taxonomies and/or ontologies. The proposal defines:

“The objectives of taxonomy structure, accompanied with data model and ontology for EPISECC use

case, is to facilitate:

communication - by building a common structure of crisis management systems understood

by all involved parties in critical events/disasters (despite of different culture, practice,

expertise etc.);

interoperability - by building common context in terms of data, processes, management tools

and business models used in different events used by all services in the security field,

enabling them to work together;

development of the Common Information Space - by structuring data and processes;

standardisation - by building formal, easy to search models and structures of security

services' business models, enabling efficient and consistent transfer of the developed

models into standards.”

The proposal has recognized several challenges for informational interoperability. The following

three are of most important ones for the data model:

utilisation of existing and emerging standards;

utilisation of the EPISECC Taxonomy;

dynamic information sharing .



www.episecc.eu

The proposal describes utilisation of the Taxonomy as: “The taxonomy developed within this project

shall be utilised as a framework of common processes and data sets. Data models, developed based

on common data sets, will serve to structure data in the Common Information Space. Adaptors /

translators / mapping services shall allow mapping of structured information from the manifold

existing semantic spaces to a common information space in order to establish interoperability across

services, cultures and languages.”

Dynamic information sharing is described as: “Within this project, the common information space is

not regarded as something static, but more as a dynamic space, where additional participants can be

added spontaneously as required by the mission.”

From the above described objectives and challenges, the data model should be designed to meet the

following objectives:

to utilize the EPISECC taxonomy;

to structure data in the Common Information Space;

to support semantic mapping services;

to allow additional participants to be added as required.

The above data model’s objectives define the main applications and scope of the CIS database. Data

model requirements further elaborate these objectives and they are described in the following

paragraphs.

3.2. Study of data models used by information tools

The Deliverable 2.1 “PPDR Information Space” - Status quo of commercial, research and

governmental projects and applications” provides an overview of projects and applications (so called

tools) used for Public Protection and Disaster Relief (PPDR) management. The deliverable clearly

identifies the gap in the area of semantic interoperability and stresses the need for semantic

harmonisation of information tools (hereinafter tools) used in EU member states and tools used in

the EU Civil Protection Mechanism. Thus, the Data model’s objectives stated in the EPISECC project

proposal (section 3.1) are proven.

Deliverable 2.2 “Dealing with natural or man-made crisis and disaster - Standards, management

approaches and good practices in information provision and exchange” has shown that disaster

management in wider Europe is characterised by a variety of standards, managements approaches

and practices used. Also, no one data model could be considered as the prevailing one in Europe.

The EPISECC project has developed a Pan-European inventory of past disasters which contains major

attributes of disasters and management practices. The inventory is described in the deliverable 3.4

“Pan-European inventory of events/disasters including business models”. The analysis shows a huge

variety across the interviewed organisations:

34 organisations use a total of 54 different standards, guidelines or recommendations for

their daily business;

33 organisations use a total of 56 different tools for their purposes in disaster management;



www.episecc.eu

about 180 requirements dedicated to improve management of disasters were expressed, the

majority of them are related to interoperability.

Regarding standards and guidelines used by organisations, the current situation derived from the

inventory is the following:

eight international standards or guidelines are used by two or more organisations;

thirteen international standards or guidelines are used by only one organisation;

six national/local standards or guidelines are used by two or more organisations;

thirteen national/local standards or guidelines are used by only one organisation.

Table 1 shows eight international and six national or local standards/guidelines used in two or more

organisations.

Table 1: Standards and guidelines used by organisations (Deliverable 4.1)

No. Standards and Guidelines Freq. Type

1 CAP (Common Alerting Protocol) 7

International

2 International Search and Rescue Advisory Group Guidelines

(INSARAG) 6

3 UNISDR Terminology on Disaster Risk Reduction 5

4 GDACS Guidelines For Information Exchange in Disaster 4

5 INSPIRE Directive 3

6 International Red Cross Society and Red Crescent Society -

Introduction to the guidelines 2

7 TSO / CWA 15931-Part 2 (Codes for the message structure) 2

8 Sphere Handbook - Minimum Standards in Humanitarian Response 2

9 SKKM Richtlinie für das Führen im Katastropheneinsatz (SKKM

Directive for Leading Organisation in Disaster Relief) (Austria) 7

National

and/or

local

10 Italian decree - Fire Brigades - Adoption of common format for

emergency data sharing (CAP) 3

11 Italian decree - Fire Brigades - CAP Italian Profile and distribution

mechanism 3

12 Xkatastrophenhilfe (X Disaster Relief) (Germany) 2

13 Regulations on Mutual Relations of Fire Brigades During Fire

Interventions (Croatia) 2

14 Standard operating procedures (Croatia) 2



www.episecc.eu

The Common Alerting Protocol (CAP) [8] is the most commonly used standard noted by seven

organisations. It is an XML schema for alerting messages consisting of 44 information elements of

which 13 are mandatory. The elements are grouped in four blocks. The value of an information

element could be free text, a defined data format such as date-time format or a URI address referring

to additional data resource and predefined list of words or codes. For example, the predefined list for

the element describing “Severity” contains the words: “Extreme”, “Severe”, “Moderate”, “Minor”

and “Unknown”. Another example, the free text element “Instruction” contains textual description of

the recommended action to be taken by recipients of the alert message. Additionally, users can add

their own elements describing different parameters such as, for example, magnitude for an

earthquake.

TSO/CWA 15931-Part 1 draft technical report describes a message structure for the information

exchange between organisations [9]. The message structure is called Emergency Management

Shared Information (EMSI) and it describes the operational picture via the following descriptions:

identification of the EMSI message (message identifier, its originator, relation to other

message etc.);

description of the event (data and time, location, number of casualties, etc.);

description of the resources (available resources, their capabilities, position etc.);

description of the missions (the missions in progress, the missions foreseen).

In 2015, TSO/CWA 15931 became technical report ISO/TR 22351, Societal security - Emergency

management - Message structure for exchange of information (EMSI) [18]. Figure 3 shows the EMSI

message UML class diagram. A data element in the EMSI message contains strings or numbers

representing names, measurements, descriptions etc. and values constrained to a fixed list of valid

values called EMSI codes. EMSI codes are structured as a hierarchy of code elements and they

represent real world concepts. For example, the code “MAT/VEH/ROADVE/FRFGTN/BREATH”

expresses the following hierarchical path: “Material”, “Vehicle”, “Road vehicle”, “Fire appliance”,

“With breathing apparatus support”. The corresponding real world concept must be interpreted by

the user who reads the EMSI message. For the code example “MAT/VEH/ROADVE/FRFGTN/BREATH”,

the concept could be: “Road vehicle with fire appliance including breathing apparatus support”.

The analysis of data models of the eight international and six national or local standards/guidelines

used in two or more organisations (Table 1), revealed the following:

four standards/guidelines include data models as XML schemas: CAP, Xkatastrophenhilfe

and two Italian standards based on CAP, the models include lists of predefined values (words

or codes) for some data elements;

two standards/guidelines include data models as UML diagrams: INSPIRE and EMSI, the

models include lists of predefined values (words or codes) for some data elements;

other standards/guidelines include terminology as text at the beginning of documents.



www.episecc.eu

The analysis of the inventory (Deliverable 4.1) indicates the main tools for communication between

emergency teams as follows:

voice over different means of communication (landline, GSM, TETRA or personal meetings),

plain text in e-mails via IP networks, mostly public.

Figure 3: UML class diagram of EMSI messages standard [18]

The analysis of the inventory regarding the tools used by end users during disasters (Deliverable 4.1)

shows that data exchange using tools is not a practice. That is because there are almost no common

tools in use. Organisations are using their own preferred tools which are, in many cases, proprietary

tools. Only three tools are used in 24% of the cases described in the inventory: CECIS, UN/OCHA

Relief Web and Virtual OSOCC. They are tools provided centrally by UN/OCHA and/or the EC/ERCC.

First responders cannot directly exchange information between the proprietary tools. They read the

information and then create a plain text message that can be shared.

Based on the above described data models used by tools, the requirements on the EPISECC Data

model are derived. Table 2 summarises the findings about currently used data models and

corresponding EPISECC Data model requirements.



www.episecc.eu

Table 2: Data models used by tools and corresponding Data model requirements

No. Data models used by tools EPISECC Data model requirements

1 No data model prevails in Europe.

EPISECC Data model can be developed from the

scratch or by adapting any of the existing

models.

2

Semantics of data are stored in various

structures mostly as description of

terminology at the beginning of

standards or guidelines.

EPISECC Data model should be able to store

various semantic structures such as

terminology, glossary, thesaurus, XML schemas,

UML diagrams, taxonomies, coding systems etc.

3

CAP standard is the most commonly used

standard for alerting messages. It is XML

schema which includes codes and allows

users to add their own data elements.


CAP XML schema and its codes, allowing users

to add their own data elements with their own

semantics.

4

EMSI draft technical report includes UML

class data model together with

comprehensive code dictionary with

hierarchical structure.


EMSI data model and its code dictionary with

hierarchical structure.

5

Unstructured data prevails because voice

and e-mails are dominant

communication tools.

Voice can be converted to text via special

tools and treated as text from e-mail

messages.


semantics included in unstructured data like e-

mails or free text.

It could be done by enabling users to fill the

database with their own concepts. Data model

should enable continuous updating by users.

EPISECC Data model requirements in Table 2 clearly state that the EPISECC Data model should be

designed to store various semantic structures which organisations use for the description of their

concepts. The semantic structures are terminologies, glossaries/dictionaries/vocabularies, thesauri,

XML schemas, UML diagrams, taxonomies and coding systems. Unstructured data could be described

with its concepts and thus the EPISECC Data model should enable users to fill the database with their

own concepts and also to continuously update the database. Figure 4 illustrates various semantic

structures to be stored by the EPISECC Data model.



www.episecc.eu

Figure 4: Various semantic structures to be stored by the Data model

3.3. The EPISECC Taxonomy structure

The importance of the EPISECC Taxonomy structure for the EPISECC Data model requirements comes

from two perspectives. From the project proposal perspective, the utilisation of the EPISECC

Taxonomy is the main data model’s objective. From the perspective of RDF data model design, the

first step is to model the domain knowledge (definitions of basic concepts and relations among

them). In the EPISECC project, the key source of domain knowledge is the EPISECC Taxonomy.

Therefore, it is considered as the main semantic structure which should be supported by the EPISECC

Data model.

The developed taxonomy is tailored to fulfil the following objectives (Deliverable 4.2):

to describe end-users’ formal definitions from dictionaries and/or taxonomies, as well as

everyday communication;

to incorporate existing concepts from commonly used standards, domains or classes at

certain level of abstraction, used by system developers.

The EPISECC Taxonomy has a distinctive universe of discourse “a response to a critical event”, which

is focused on the disasters’ relief period, namely first 72 hours after disaster’s sudden impact or early

warning system’s alert (Deliverable 4.2). Generic concepts such as time, space and metric systems

are not included in the EPISECC Taxonomy since they are not exclusively related to “a response to a

critical event”. The structure of the EPISECC Taxonomy is a combination of hierarchies and facets,

where hierarchy is represented by “IS-A” relationships between concepts and facets are independent

Data model

unstructured

data

glossary

dictionary

vocabulary

thesaurus

taxonomy XML schemas

UML diagrams coding systems

unknown,

future one



www.episecc.eu

concepts. Every concept and facet has a description and is represented by a term, which may also be

considered as their name. With faceted taxonomy, each real object can be classified using a

compound term, which is a set of terms from one or several facets (Deliverable 4.2). The current

version of the EPISECC Taxonomy has 45 facets and 315 concepts. It is preliminary internally

validated against the episodes and use cases developed and presented in deliverable D4.1 and

results show that the main concepts related to the information exchanged during emergency

management are included. The external validation which will include end users and project’s

Advisory Board members is planned within WP6, during the Proof of concept phase (Deliverable 4.2).

The requirements on the EPISECC Data model imposed by the EPISECC semantic structure are as

follows. The Data model should be able to store:

concepts, their terms and descriptions,

facets, their terms and descriptions,

a hierarchy of concepts (IS-A relationship between the concepts),

relationships between concepts and facets (showing facets used to classify the particular

concept),

compound terms.

The EPISECC Data model should be able to store the whole EPISECC Taxonomy structure and allow

users to add their own compound terms. Additionally, the Data model should be able to store

generic concepts such as time and space which are not included in the EPISECC Taxonomy but are

necessary to encompass the emergency management domain knowledge.

3.4. Common Information Space design

The EPISECC project proposal defines: “Taxonomy and data model will serve WP5 to establish a new

model of common information space and also WP9 for initialising of standardisation process.

Moreover, the EPISECC use case ontology model will serve for design (WP5) and proof and validation

of new "common information space" (WP6)”. Therefore, the EPISECC Taxonomy and accompanying

data model have to support the semantic interoperability of organisations and their tools that are

intended to exchange information by the means of the Common Information Space (CIS). The

proposal describes the architecture of the Common Information Space as: ”The architecture of the

common information space shall show how the developed taxonomy can be used within real crisis

management systems (consisting of organisations, procedures and technical tools) in order to

enhance the collaboration within and effectiveness of crisis management.”

The main idea of CIS is to share information automatically between tools of different emergency

organisations that don’t have dedicated interfaces for daily cooperation. Instead of developing

specific interfaces for every (potential) pair of tools (Figure 5a), CIS provides standardised interfaces

that need to be implemented one per tool (Figure 5b).



www.episecc.eu

Figure 5: Tools interfaces without CIS (a) and with CIS (b)

The CIS interfaces should ensure physical (data connection), syntactical (data formats), and semantic

(interpretation of the content) interoperability. The syntactical and semantic interoperability are

interrelated because syntaxes may include pre-defined concepts definitions and namespaces. From

the syntactical point of view, the shared information is transported within the CIS as standard

messages using standard formats such as CAP and EMSI (Figure 6). The common taxonomy defined

by EPISECC project is used for the semantic mapping of key terms used by the cooperating

organisations (e.g. Agent A taxonomy and Agent B terminology shown on the Figure 6). The process

of semantic mapping is foreseen only for concepts which are not pre-defined by syntax because

syntax dependant concepts are translated during syntax conversion. Also, a free text is not foreseen

to be included in the semantic mapping procedure during the project lifetime.

Figure 6: The role of the taxonomy in CIS (Deliverable 4.2)

An example of interrelationship between syntactic conversion and semantic mapping follows. While

creating/interpreting the standard messages sent/received via CIS, a CIS software component

(hereinafter also referred to as the CIS Adaptor) has to convert proprietary’s interface syntax of the



www.episecc.eu

connected tool to the CIS standard syntax. Also, the CIS Adaptor has to semantically match concepts

used by organisation that sends a message with the concepts used by organisation that receives the

message. This means the following:

firstly, the CIS Adaptor has to convert the elements of the tool’s syntax to the elements of

the CIS standard syntax (syntactical interoperability);

secondly, the CIS Adaptor has to semantically match the concepts of the sender and recipient

organisation, thus allowing semantic interoperability. This may comprise both, semantic

mapping of proprietary terms of the connected tool to corresponding values defined by the

CIS standard syntax used to transport the information, and mapping of proprietary terms of

the connected tool to concepts in the EPISECC Taxonomy.

The above described processes of semantic mapping and semantic matching will be implemented in

CIS through development of a sub-system called Semantic Mapping, a part of CIS Adaptor. The

objective of the sub-system is to automatically interpret meanings of exchanged information

between the cooperating organisations. To achieve this, the prerequisite is that cooperating

organisations map their concepts to a common EPISECC Taxonomy and to store these semantic

mappings to be used by CIS. Therefore, the CIS sub-system Semantic Mapping includes a database for

the storage of the EPISECC Taxonomy, the organisation’s concepts and semantic mappings of

organisations concepts to the EPISECC Taxonomy.

3.4.1. Semantic interoperability processes

Semantic interoperability in the emergency management, as seen from the perspective of the

European Interoperability Framework for European public services [19], ensures that the precise

meaning of exchanged information is understood and preserved throughout exchanges between

organisations. As stated in [19], achieving semantic interoperability in the EU context is a relatively

new undertaking and a starting point is to create sector-specific sets of data structures and data

elements that can be referred to as semantic interoperability assets. In the context of the EPISECC

project, the EPISECC Taxonomy represents such an interoperability asset accompanied by two

semantic interoperability processes. Semantic mapping and semantic matching are two processes

deployed to automatically interpret meanings of exchanged information between the cooperating

organisations. Both processes are included in the CIS sub-system Semantic Mapping.

Semantic mapping could be performed as follows:

as a translation, using 1:1 mapping between concepts from different organisational

structures;

as an advanced translation, if mapping between concepts is not restricted to 1:1;

as a classification, if concepts from an organisational structure are classified against special

purpose structure, a taxonomy.



www.episecc.eu

Semantic mapping, which will be performed in CIS, includes not only classifying of organisation's

concepts against the EPISECC Taxonomy and/or concepts from accompanied generic domains (e.g.

space, time) but also storing the results of the process.

The relation between organisation’s concept and correlated concepts in the taxonomy is defined as

“belongs to class” and is stored in the database. Semantic mapping of organisations’ concepts against

the EPISECC Taxonomy and/or accompanied generic domains must be done before the information

exchange via CIS begins. During semantic mapping, the expert performs classification of emergency

organisation’s concepts against the EPISECC Taxonomy and/or accompanied generic domains and, if

necessary, the compound terms from facets are created from.

Semantic matching is a process of retrieving the concepts of emergency organisation that receives

the message which semantically match the concepts of the emergency organisation that sends the

message. The semantic matching between the concepts of two organisations is done via the EPISECC

Taxonomy and/or accompanied generic domains when both organisations have already mapped

their concepts to the EPISECC Taxonomy and these mappings are stored in the database. Thus, the

semantic matching process includes querying of the database for the concepts satisfying the

conditions defined by the SPARQL queries and, if necessary, inferring new semantic mappings

between concepts by use of reasoning.

3.4.2. Draft design of CIS sub-system Semantic Mapping

Based on the previously described processes of semantic mapping and semantic matching, a draft

design of the CIS sub-system Semantic Mapping and Matching is developed. Figure 7 shows an UML

Use case diagram of the CIS sub-system Semantic Mapping/Matching. Five use cases are used by two

actors. The Use case 2 performs Semantic mapping while the Use case 3 performs Semantic

matching. The use cases are the following:

Use case 1: Enter semantics

The Semantic mapping expert enters emergency organisation's semantics (concepts, their

definitions and, if existing, their semantic relations e.g. a hierarchy structure) in the Semantic

Repository.

Use case 2: Enter semantic mappings

The Semantic mapping expert maps emergency organisation's concepts to the EPISECC

Taxonomy’s concepts or concepts from other domains (e.g. time, space). These semantic

mappings are stored in the Semantic Repository.

Use case 3: Create compound terms

If needed, during mapping of emergency organisation's concepts to the EPISECC Taxonomy,

the Semantic mapping expert will create the compound terms by using the EPISECC

Taxonomy facets.



www.episecc.eu

Use case 4: Request semantic matching

The CIS Semantic Adaptor requests concepts of the emergency organisation that receives the

message which semantically match the concepts of the emergency organisation that sends

the message. The request is performed against the Semantic Repository.

Use case 5: Infer semantic relations

If needed, in case not all the semantic relations are stored in the Semantic Repository, the

request for semantic matching can be extended with the reasoning algorithm which will infer

additional semantic relations and store them in the Semantic Repository.

The actors are the following:

Semantic mapping expert

A person authorised to enter emergency organisation’s concepts into the Semantic

Repository and to map them to the EPISECC Taxonomy’s concepts or other domains’

concepts. During semantic mapping, the Semantic mapping expert creates the compound

terms from the EPISECC Taxonomy’s facets. The Semantic mapping expert can be an

employee of the emergency organisation or an external consultant.

CIS Semantic Adaptor

A part of the CIS Adaptor (called Semantic Mapping Services) responsible for retrieval of

semantically matched concepts of two emergency organisation by use of the Semantic

Repository. Section 3.4.3 includes its detailed description.

Figure 7: UML Use case diagram of CIS sub-system Semantic Mapping

The CIS sub-system Semantic Mapping includes a database called Semantic Repository for the

storage of the EPISECC Taxonomy, the organisation’s concepts and semantic mappings of

organisations concepts to the EPISECC Taxonomy. Generic concepts such as time, space and metric



www.episecc.eu

system will be stored in the Semantic Repository to provide common semantic descriptions of these

domains.

The additional requirements on the EPISECC Data model by the draft CIS design are regarding

creation and maintenance of the Semantic Repository, particularly the concepts and semantic

mappings. The requirements are the following:

The EPISECC Data model should enable extension of the EPISECC Taxonomy if additional

concepts are needed. This triggers updating of semantic mappings already stored in the

Semantic Repository. Therefore it has to be carefully analysed if an extension is necessary or

if existing semantic relations satisfy the needs (e.g. use of “broader match” or mapping

between two concepts when concept A has broad match in Concept B).

Emergency organisations will store and maintain their concepts and semantic mappings to

the EPISECC Taxonomy in the Semantic Repository. The considerations are:

o semantic mapping has to be able to cope with ambiguity if no 1:1 relation exists;

o several terms of the organisation may be mapped to one (broader) concept of the

EPISECC Taxonomy, and several EPISECC concepts may be mapped with one term of

the organisation. In both cases rules for the inverse mapping have to be defined and

stored in the data model;

o semantic mapping should ensure that no mapping ambiguity appears in the Semantic

Repository.

3.4.3. Draft design of semantic mapping and matching processes

The EPISECC project considers semantic mapping as a process of connecting two concepts in the

Semantic Repository using their semantic similarities. Particularly, it is the process of identifying the

most appropriate match between end users’ concepts or codes and the concepts of the basic sub-

structures in the Semantic Repository: EPISECC Taxonomy, EMSI coding system as well as generic

concepts for time, space and measuring units.

In the context of the EPISECC project, an additional process is introduced: the semantic matching.

Semantic matching is matching between the concepts of two organisations via the EPISECC

Taxonomy. Prerequisite for the semantic matching is that both organisations have entered their

concepts and mappings against the EPISECC Taxonomy concepts in the Semantic Repository. Then,

the semantic matching is performed by executing SPARQL queries over the Semantic Repository and,

if necessary, inferring new semantic mappings by reasoning.

Different semantic structures (hereinafter called sub-structures) will be stored within the Semantic

Repository, based on the Data model approach described in Chapter 4. The semantic sub-structure

describes the concepts and related terms or codes, belonging to an emergency organisation. The

EPISECC Taxonomy is stored in the Semantic Repository as a semantic sub-structure too.

The semantic matching makes use of specific software services and the content of the Semantic

Repository to realise the entire process. The organisation that sends the information to the CIS is



www.episecc.eu

called hereinafter the Source and the organisation that receives the information is called the

Destination. The process of semantic matching includes the following:

firstly, the concepts from the information send by the Source are selected and provided as an

input to the second step, also, the names of the Source and Destination semantic sub-

structures are provided too

secondly, by executing a SPARQL query over the Semantic Repository with the parameters

given from the previous step, the semantically matched concepts of the Destination to the

Source concepts are retrieved and provided to the third step

thirdly, the retrieved concepts of the Destination are added to the information of the Source

to improve understanding of the Destination

The steps described above correspond to the “Use case 4: Request semantic matching” from the

draft design of the CIS sub-system Semantic mapping (Figure 7). Detailed technical description of the

implementation and testing of these steps is given in the section 5.2.

3.4.4. Example for semantic matching

Let’s consider a generic use case, where the Organisation A needs to share information with both

Organisation B and Organisation C using the CIS. In such a case and as depicted in the Figure 8 the

following procedure’s steps occur as follows:

1. relevant concepts’ terms or codes from the information set of Organisation A (the source

sub-structure) are selected either by Organisation A or automatically by the Semantic

Mapping Services of the CIS (software component TTBox in the Figure 8) by reading a

message provided as input (e.g. standard message CAP);

2. relevant concepts’ terms or codes from Organisation A (the source sub-structure) are used

within SPARQL queries, in order to find the matching concepts in the Semantic Repository’s

basic sub-structures (destination sub-structure, the EPISECC Taxonomy);

3. the result of the SPARQL queries is returned back through the TTBox component;

4. the original message / information set is enriched by including the matched concepts found

in the Semantic Repository’s basic sub-structures (the EPISECC Taxonomy) before to be sent

to the Organisation B and Organisation C;

5. the enriched message is sent to the CIS component on the sender side (Organisation A) in

charge of performing the distribution to the other tools (Distributor);

6. the enriched message is distributed to Organisation B and Organisation C (through the

corresponding CIS Distributors);

7. the information (e.g. standard CAP message enriched with the matched concepts of the

EPISECC Taxonomy) is taken over by other components in the receiver chain, in charge of

handling the reverse semantic matching;

8. once the information reaches Organisations B and C, a new matching is requested so that the

key concepts or codes in the Sematic Repository’s basic sub-structures (the EPISECC



www.episecc.eu

Taxonomy is now the source sub-structure) can be matched to the terms or codes of

Organisation B and Organisation C respectively (now, the destination sub-structures);

9. new SPARQL queries are executed over the Semantic Repository (see also step 2);

10. the results are returned back to Organisation B and C respectively (see also step 3).

Figure 8: Process of semantic matching by use of Semantic Mapping Services of CIS

In order to make the realisation of the above described generic use case possible, and as described in

the Section 3.4.2 and shown on Figure 7, the Organisations A, B and C should have performed the

following steps before the information exchange and the semantic matching has started:

1. enter their concepts, either structured or unstructured, in the Semantic Repository, and

2. map their concepts to the EPISECC Taxonomy, the Semantic Repository’s basic sub-structure.

Most of the information that needs semantic mapping for mutual understanding between

cooperating emergency organisations is composed by either simple or complex concepts and codes

belonging to the predefined semantic structures like unstructured sets, simple alphabetically ordered

lists or more complex structures. Such structures will be stored in the Semantic Repository and

mapped to its basic sub-structures. Hence, each time one of the terms needs to be transferred

together with other information in the CIS, corresponding concepts will be firstly matched to the

Semantic Repository’s basic sub-structures. Similarly, each time one of terms is received by one of

the cooperating organisation, the matching from the Semantic Repository’s basic sub-structures to

the cooperating organisation’s sub-structure is performed.

An important aspect is related to the approach for the definition of the Mapping Set, i.e. the specific

set (and type) of information that needs to be semantically matched using the technical approach

outlined in the previous paragraph and illustrated in Figure 8. The following example shows the



www.episecc.eu

approach for defining the Mapping Set in case information is provided in CAP format by the

Organisation A and send to Organisation B and Organisation C. Let’s consider the simple CAP

message described in Figure 9.

<alert xmlns="urn:oasis:names:tc:emergency:cap:1.2">

<identifier>1234567</identifier>

<sender>Organisation-A</sender>

<sent>2016-02-09T10:07:01+01:00</sent>

<status>Actual</status>

<msgType>Alert</msgType>

<source>Organisation A</source>

<scope>Private</scope>

<addresses>Organisation-B Organisation-C</addresses>

<info>

<language>it-IT</language>

<category>Other</category>

<event>Terremoto</event>

<urgency>Urgent</urgency>

<severity>Severe</severity>

<certainty>Observed</certainty>

<eventCode>

<valueName>Code_L1</valueName>

<value>Crollo</value>

</eventCode>

<eventCode>

<valueName>Code_L2</valueName>

<value>Crollo edificio</value>

</eventCode>

<headline>Crollo di intero edificio con assistenza richiesta</headline>

<description>5 piani. Tutto crollato</description>

<parameter>

<valueName>INCIDENT PROGRESS</valueName>

<value>Squadra sul posto</value>

</parameter>

<parameter>

<area>

<areaDesc>Catania</areaDesc>

<circle>41.90034,12.4993 0.01</circle>

</area>

</info>

</alert>

Figure 9: Example of information sent in CAP format



www.episecc.eu

Considering the way CAP messages are defined, the following simple rules are taken into account to

define the Mapping Set:

generic information in the main <alert> block used for identifying the message, the sender,

the intended recipients and to provide date and time information of the event, is not

considered for the semantic matching;

only fields within the CAP <info> blocks are considered for semantic matching as they

provide the description of the event, usually with the use of organisation/user terms and

identifiers (fields such as event, event code and parameters)

fields allowing only a predefined set of values provided by the CAP specifications, such as

<category>, <urgency>, <severity> and <certainty>, may be considered for semantic

matching during the preparation of the message itself. Alternatively, such fields may be filled

in by the tool owners;

geographic information about the event, such as area description or geographic coordinates,

is not considered for semantic matching because it is often in standard format and

understood by everyone.

Fehler! Verweisquelle konnte nicht gefunden werden. provides detailed information about the

above described rules by referring them to the CAP message example given in the Figure 9.

Table 3: Semantic matching rules

Information field / field

category Nature of information within the field Semantic matching / handling

event:Terremoto This will usually contain a string belonging

to a predefined set / list of terms (the

organisation semantic structure). In this

example, the term “Terremoto” is used,

which in Italian stands for “Earthquake”.

Organisations should map the

terms or codes used in the

<event> field “as they are” to

the corresponding EPISECC

Taxonomy concepts.

eventCode

valueName: Code_L1

value:Crollo

The <value> used within an eventCode

block contains a string belonging to a

predefined set / list of terms (the


example, the term “Crollo” is used, which

in Italian stands for “Collapse”.



<eventCode> fields “as they

are” to the corresponding

EPISECC Taxonomy concepts.



www.episecc.eu

Information field / field

category Nature of information within the field Semantic matching / handling

eventCode

valueName: Code_L2

value:Crollo edificio





example, the string “Crollo edificio” is

used, which in Italian stands for “Building

collapse”.



<eventCode> fields “as they



parameter

valueName:

INCIDENTPROGRESS

value: Squadra sul posto




organisation semantic structure), but not

for all the parameters in the CAP. Specific

<parameter> blocks used by the tools and

carrying custom key terms or codes, may

be included in the matching but they need

to be known and configured in advance.

Meaning that for such <parameter>

blocks, the keywords used in

<valueName> must be pre-configured to

identify the terms that need to be

translated.



<parameter> fields “as they





www.episecc.eu

4. Data model design

This chapter introduces a concept of semantic repository as a place where semantic descriptions will

be stored in the CIS. Thus, the EPISECC database is called Semantic Repository and the EPISECC

Taxonomy is its backbone or main semantic sub-structure. Other sub-structures contain generic

concepts such as time and space or organisation’s concepts. The RDF data model is selected for the

Semantic Repository as state-of-the-art for the semantic interoperability and the SKOS-thes model is

selected as standard model for semantic descriptions. The following paragraphs briefly describe the

RDF model and underlaying semantic web technologies while the SKOS-thes data model and its

introduction to the EPISECC project are described in more details. The Data model decribed in this

chapter is the first version of the EPISECC Data model since it will be further validated in WP6 and

elaborated in the Deliverable D4.5.

4.1. The EPISECC project Semantic Repository

Chapter 3 describes the EPISECC Data model requirements for the EPISECC database and introduced

it as the Semantic Repository. The highlights of the requirements are as follows.

The EPISECC database (hereinafter the Semantic Repository) should:

serve as Semantic Repository of the CIS

support storage of various semantic structures

support semantic mapping and semantic matching applications in CIS

support adding additional participants as required

In the design of the CIS sub-system Semantic Mapping the Semantic Repository is defined as a place

where semantic descriptions will be stored. The Semantic Repository as one structure will contain

several sub-structures describing semantics of particular domains. The main sub-structure is the

EPISECC Taxonomy. There are additional sub-structures describing concepts of organisations.

Organisations can use terminologies, dictionaries, XML schemas, coding systems etc. Generic

concepts such as time, space, observations and units will be described by the semantic descriptions

given in GeoSPARQL vocabulary [4], W3C time ontology [5], SWEET ontology [6] and QUDT ontology

[7] but accommodated to the EPISECC Taxonomy structure. CAP [8] and EMSI [18] will be included as

sub-structures as standards used in the emergency management. The semantic relationships

between concepts from different sub-structures will be stored too.

Figure 10Figure 10 illustrates the content of the EPISECC Semantic Repository. The blue links show

semantic relationships established between concepts of the sub-structures to the EPISECC

Taxonomy. Generic concepts will be modelled as facets in the EPISECC Taxonomy. The semantic

matching between organisations’ concepts will be done via the EPISECC Taxonomy.

The design of the Semantic Repository as RDF data model does not limit the semantic matching

process to be done only via one common semantic structure, such as the EPISECC Taxonomy.

Instead, the concepts of two organisations can be mutually mapped, or mapped to another semantic



www.episecc.eu

structure stored in the Semantic Repository. But these methods are not foressen during the project

lifetime.

Figure 10: Content of the Semantic Repository

The EPISECC project consortium has decided to use the RDF data model for the Semantic Repository.

The decision is based on the fact that the RDF data model represents a state-of-the-art for the

semantic interoperability as will be explained in the following Section 4.2. Also, the decision is based

on the judgement that the RDF data model can fit the CIS design and is a already deployed

technology. In short, the RDF data model brings the following benefits to the CIS concerning semantic

interoperability:

the Semantic Repository is „open world” opposite from „closed world”, what means that it

supports on-going development of terminologies, dictionaries, coding systems etc:

o any time any organisation’s semantics can be added,

o any time any domain’s semantics can be added,

o any time any concept can be added/deleted,

o any time any relationship can be added/deleted;

via RDFS and OWL, the database schema describing data semantics can be distributed

together with data what enables semantic interoperability;

a standardized technology is used for rarely standardized vocabularies, taxonomies, thesauri,

data models etc. used in the emergency management.

The following section explains the RDF model and underlying technology of semantic web necessary

to deploy the Semantic Repository.



www.episecc.eu

4.2. State-of-the-art for the semantic interoperability

Tools used for human communication such as phone, e-mail and web pages use human capacity to

interpret and give meanings to the spoken or written words. The interpreted meanings depend on

the context of the readers and varying interpretations are given to the terms used to describe

concepts. Consequently, the problem of semantic heterogeneity arises. Cognitive and naming

semantic heterogeneity are described in [20]. Cognitive semantic heterogeneity is when the same

concept has various definitions given by the groups of people having different cognitive views of the

world. Naming semantic heterogeneity happens when the same term is used for different concepts

or different terms are used for the same concepts. To improve semantic interoperability, the degree

of semantic heterogeneity in the human communication must be lowered.

Ontologies are widely recommended as a means of resolving semantic heterogeneity [21]. In the

context of philosophy, ontology is dealing with the nature of being, but in the context of computer

sciences, Thomas Gruber defined ontology as explicit specification of conceptualisation [22]. In the

context of database systems, ontology represents a data model consisting of a set of elements with

which to model a domain of knowledge or discourse. The elements are classes, properties and

relations among class members. Ontology includes description of meanings of elements and

constraints on their logically consistent application. Today, ontologies are used as a layer in the

technology stack of the semantic web standards [23]. Figure 11 illustrates the architecture of the

semantic web.

Figure 11: Semantic Web technology layer stack [24]

The main idea of the semantic web is to provide a medium in which people can collaborate by

sharing information [15]. The semantic web is state-of-the art technology aiming towards semantic



www.episecc.eu

interoperability of data. Uniform Resource Identifiers (URI) are used as global references to data

items distributed over the web. Figure 11 shows URI as a fundamental layer of the semantic web

stack together with the RDF data model. RDFS and OWL are languages for describing the RDF data

model by ontologies. SPARQL is an RDF query language and Rule Interchange Format (RIF) is a

standard for exchanging rules among web rule engines. The upper layers of the semantic web stack

are not yet standardized or developed. The World Wide Web Consortium (W3C) has initiated

development of the semantic web which refers to a vision of the web of Linked data. RDF, RDFS,

OWL, RIF and SPARQL are W3C standards for the semantic web enabling people to create data stores

on the web, build vocabularies, and write rules for handling data.

The semantic web aims to achieve some degree of semantic interoperability in the open world. The

assumptions of the open world are the following:

anytime new information may arrive

not everyone will agree and multiple viewpoints must coexist

Emergency management could be considered as the open world because it encompasses the above

described assumptions. The open world assumptions have implications on semantic descriptions of a

human domain or the ontologies. In the open world there will never be one single ontology everyone

agrees. Just the opposite, there will always be multiple ontologies describing semantics of the same

or overlapping domains. The challenge is not to build single ontology, but to provide a single formal

model for the ontology description readable by computers. Such model will enable the federation of

data with different semantics. The W3C’s RDF standard is model for storing data and its ontologies,

and RDFS and OWL are standard languages for writing ontologies. These are the state-of-the art

models aiming towards semantic interoperability of data.

4.2.1. RDF data model

The RDF data model is a W3C standard [25]. The specifications and on-going development are

available on the W3C web pages [26]. The RDF data model is state-of-the art in data modelling for

distributed data.

The RDF data model enables data to be distributed across the web and to be merged for data search

and queries. Even if the underlying database schemas (conceptual models) differ, data can be

merged because its logical model is always the same. The RDF logical model is a Triple consisting of

Subject, Predicate and Object and it is represented by a directed graph (Figure 12).

Figure 12: RDF Triple



www.episecc.eu

Comparing with data stored in the relational data model (the most common data model used today)

one table cell in relational table contains one Triple of data. One table cell in the relational database

stating that Vehicle no. 3 has capacity of 8 people will be represented in RDF database as Triple

(Vehicle no.3, hasPeopleCapacity, 8).

The idea of distributing data over the web is realized by use of Uniform Resource Identifiers (URI) as

global references to data items. Triple elements can contain URIs or literal values. Storing of URIs

means that data items are refering to the resources anywhere on the web. Table 3 shows several

triples from an RDF database containing the EPISECC Taxonomy stored on the Stanford University

server. Under the Subject, URIs represent identifiers of the subject and they point to resources on

the University Stanford server. Predicate data items represent standard RDFS properties stored on

the W3C organisation server. Object data items are URIs or literal values. Object URIs represent

standard OWL classes or identifiers of the EPISECC Taxonomy individuals.

Table 4: Triples of the EPISECC Taxonomy stored in RDF data model

Subject Predicate Object

http://webprotege.stanford.edu/R7Qoh6fSXLYyOs4ui2ijD6k

http://www.w3.org/2000/01/rdf-schema#comment

"An organisation manages activities at strategic level."

http://webprotege.stanford.edu/R7RqFIXDaygay75ZxZl5SHT

http://www.w3.org/1999/02/22-rdf-syntax-ns#type

http://www.w3.org/2002/07/owl#Class


http://www.w3.org/2000/01/rdf-schema#label

"Medical aid data"


http://www.w3.org/2000/01/rdf-schema#subClassOf

http://webprotege.stanford.edu/RB3YiyYGZD4U02QDozyWhHe



"Data on the availability of hospital resources."

http://webprotege.stanford.edu/R7V7wRwuLHNSWW9SGjWipz7

http://www.w3.org/1999/02/22-rdf-syntax-ns#type

http://www.w3.org/2002/07/owl#Class


http://www.w3.org/2000/01/rdf-schema#label

"Emergency medical service"


http://www.w3.org/2000/01/rdf-schema#subClassOf

http://webprotege.stanford.edu/R8tvv5TWr9kcWWEdfTTMfPM



"An ability to treat and transport people that may be life threatening or injured during a response to a critical event."

Since URIs can be long, Qnames are used. An URI is divided into two parts: a namespace and an

identifier. Namespaces have abbreviations which must be declared in the database. E.g. URI

http://www.w3.org/2000/01/rdf-schema#comment can be written as rdfs:comment where rdfs is the

abbreviation for the namespace http://www.w3.org/2000/01/rdf-schema# and comment is the

identifier. The W3C has defined standard namespaces as follows:

rdf for identifiers used in RDF, it is a prefix for URI



www.episecc.eu

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

rdfs for identifiers used in RDFS language, it is a prefix for URI

http://www.w3.org/2000/01/rdf-schema#

owl for identifiers used in OWL language, it is a prefix for URI

http://www.w3.org/2002/07/owl#.

RDFS and OWL languages are based on the RDF model and are used for the description of the RDF

database schema. The RDF database schema is stored together with data in the RDF data model

meaning that the database schema describing data semantics can be distributed together with data.

Figure 13 shows the RDF database as part of the Knowledge system. Data is asserted in ABox as an

assertion part of the RDF database and the data semantics is stored in TBox as a terminology or

conceptualization part of the RDF database. Together ABox and TBox make up a knowledge base

while description languages are used to write statements in both. The inference engine is used to

reason about the knowledge base and use logic rules to infer new facts or check logical

inconsistencies in the knowledge base.

Figure 13: Architecture of Knowledge base [27]

4.2.2. Semantic web architecture

Besides description and reasoning some other components are necessary to deploy an RDF database.

Figure 14 shows the semantic web application architecture. The Parser reads text and writes triples

into the RDF database while the serializer does the opposite; it converts triples into text files. Text

files can use any of the serialization syntaxes for RDF such as N-Triples [28], Turtle [29] or RDF/XML

[30]. To merge data not available in the RDF data model, converters and scrapers are converting

tables, spreadsheets and other data structures into RDF. Once data is merged into an RDF database,

the queries and inferences can take place. The RDF database uses SPARQL language as query engine



www.episecc.eu

for access to the database by data search and retrieval. The inference engine uses reasoning

algorithms to infer new facts from the database. Finally, applications use the content of an RDF

database via their interfaces.

Figure 14: Semantic web application architecture (adopted from [15])

SPARQL includes a protocol for communicating queries and results so that a query engine can act as a

web service [15]. Open source Apache Jena is selected as database management system for the

implementation of the Semantic Repository. Figure 15 shows SPARQL as end-point of the Semantic

Repository accessible over HTTP and JENA REST API.

Figure 15: The Semantic Repository architecture

4.3. The Semantic Repository Data model

The EPISECC Data model is developed in line with the methodology described in Chapter 2. Tasks

were the following:

search for a data model which can suit the project’s needs,



www.episecc.eu

introduce the model into the system by use of domain knowledge,

testing in Protégé Desktop.

Search for an adequate existing data model and its introduction into the project needs are described

in the following paragraphs. Testing is described in Chapter 5. The Data model implementation is

foreseen in WP5 through the realisation of the Semantic Repository in Apache Jena. The Semantic

Repository will be loaded with data from the EPISECC Taxonomy, CAP XML schema, EMSI data model

including part of the codes, GeoSPARQL vocabulary, W3C Time ontology model, part of SWEET

ontology, QUDT ontology and selected emergency organisations semantic structures.

4.3.1. The SKOS-thes design pattern

A concept “design pattern” has its origin in the object-oriented software and it describes a recurring

solution to a common problem in software design or an element of reusable Object-oriented

software. In the RDF database design, the design pattern has the meaning of a reusable RDF data

model developed for the certain domain. The main benefit to reuse an already developed RDF data

model is that it has already been proofed as a good practice shared within a community. Some of the

design patterns are recognised as industry standards or recommendations. Also, reusing of a model

saves lot of effort and enables developers to use their time in creating solutions for other common

problems and thus to contribute more to the community.

The Simple Knowledge Organisation System (SKOS) model [31] is selected as a design pattern for the

EPISECC Semantic Repository described in section 4.1. The SKOS model is a common data model for

sharing and linking Knowledge Organisation Systems (KOS) such as thesauri, classification schemes

and taxonomies via the web. KOS is part of Library Science and SKOS specifies the means for

representing and exchanging KOS in a computer network. The design goal of SKOS is to allow to map

any KOS standard to SKOS in a straightforward way. SKOS is a W3C Recommendation from the year

2008. An example of using SKOS is AGROVOC multilingual agricultural thesaurus published by United

Nations Food and Agriculture Organisation [32]. AGROVOC consists of over 32,000 concepts available

in 23 languages. Another example of using SKOS-thes is EuroVoc [33], the EU's multilingual and

multidisciplinary thesaurus covering the activities of the EU. EuroVoc contains terms in 26 languages.

To satisfy the requirements of the Semantic Repository described in the Chapter 3, the data model

must enable storage of various semantic structures including the EPISECC Taxonomy and semantic

mappings between them. Requirements include, beside the others, modelling of concepts’ terms as

separate classes, modelling facets and compound terms. As the SKOS model could not satisfy these

requirements, two SKOS extensions are selected: SKOS-XL [34] and SKOS-thes [10]. SKOS-thes

incorporates SKOS and SKOS-XL and its RDF schema (RDFS) is used as data model source in the

project (available on the web page [35]). The complete source file of SKOS-thes is given in Annex I.

The fundamental element of the SKOS model is the concept. Concepts are the units of thought or

ideas, meanings, or (categories of) objects and events. Names of concepts are stored as strings called

labels and associated with the concepts. Labels optionally include a language tag, the standard used

in HTML and XML documents for indication of language. A Concept scheme is a group of concepts



www.episecc.eu

belonging to one domain usually to one thesaurus, dictionary or similar. Concepts are related to a

Concept Scheme by establishing a relation ‘in the Scheme’. To relate concepts to one another, SKOS

uses the semantic relations broader, narrower and related from thesaurus standards. SKOS enables

concepts from various domains or concept schemas to be linked via several semantic relations: exact

match, narrow match, broad match and close match. To preserve integrity, SKOS defines a number of

integrity conditions which are expressed in RDFS or SPARQL e.g. only a concept can participate in

relations narrower, broader and related or e.g. one concept can belong to only one concept scheme.

RDFS [1] describes a data model of a RDF database using classes and properties as building blocks.

RDFS is briefly described in Chapter 2. Looking at the RDF logical model or triple consisting of Subject,

Predicate and Object, the RDFS’s class is used to model Subjects and Objects, and RDFS’s property to

model Predicate. Classes are groups of web resources, and properties are relations between subject

resources and object resources. Classes and properties are organised in hierarchies, and properties

are divided into object, data and annotation properties depending on the type of object resource

they describe (whether the object is web resource, literal value of annotation). The following

paragraphs will use RDFS classes and properties for the description of the SKOS-thes model. A short

overview of SKOS (also called SKOS-core), SKOS-XL and SKOS-thes models is given in the

Table 5. Detailed description of the selected model SKOS-thes follows.

Table 5: SKOS models

Model name and description Model graph: classes and properties (shown as links)

SKOS core

A concept is the fundamental

element of the SKOS model.

Concepts are:

identified with URIs

labelled with strings in one or more languages

documented with various types of notes

semantically related to each other in hierarchies and associations aggregated into concept schemes

can be mapped across concept schemes and grouped into labelled or ordered collections



www.episecc.eu

Model name and description Model graph: classes and properties (shown as links)

SKOS XL

Extensions to the SKOS-core are :

labels are represented by class Label

concepts can be labelled by preferable, alter, hidden and related label

label has a single literal value and two different labels can share the same literal values

SKOS-thes

Extensions to the SKOS-XL are :

compound terms are represented by class Compound Equivalence

micro-thesaurus are represented by class Concept Group

facets are represented by class Thesaurus Array

labels for compound terms and labels constituting them are represented respectively by separate classes Split Non Preferred term and Simple Non Preferred term

The SKOS-thes model is an adaptation of the standard ISO 25964 data model [36] to the SKOS

scheme. ISO 25964 is a recent standard published in two parts 2011 and 2013 respectively:

Part 1: Thesauri for information retrieval

The standard covers aspects of developing a thesaurus, monolingual or multilingual and it

includes a data model and an XML schema for data exchange.

Part 2: Interoperability with other vocabularies

The standard covers aspects of semantic interoperability or information retrieval across

networked resources that have been indexed with different vocabularies. It explains how to

establish and maintain mappings between multiple thesauri, or between thesauri and other

types of vocabularies.

While developing the new ISO standard for thesaurus, SKOS was considered as a complementary

model and the two models are aligned. The correspondence table between the two models is

documented [37] and based on it the SKOS-XL is extended. The new RDFS that provides the ISO



www.episecc.eu

25964 model was defined and called SKOS-thes model [35]. Figure 16 shows the SKOS-thes model

classes and properties as a directed graph.

Figure 16: SKOS-thes directed graph: classes and properties

The whole model contains 12 classes, 36 object properties, 3 data properties, 24 annotation

properties and 4 datatypes. SKOS-thes classes are the following:

Concept

An idea or notion; a unit of thought.

Concept scheme

Super class representing ISO Thesaurus.

Collection

Labeled and/or ordered groups of SKOS concepts. The subclasses are:

o Ordered Collection

Group of concepts placed in a meaningful order.



www.episecc.eu

o Concept Group

Group of concepts making up a subset of the Concept scheme.

o Thesaurus Array

Group of sibling concepts.

Compound equivalence

Complex concept identified by splitting the non preferred term into 2 or more (component)

preferred terms.

Label

Name of a concept composed of a string and an optional language tag. The subclasses are:

o Preferred term

Preferred label for a concept.

o Split Non Preferred term

'Imagined' concept that may exist in a user’s mind but is not present in the Concept

Scheme; it can be represented by a combination of two or more preferred terms.

o Simple Non Preferred term

Either alternative or hidden label for a concept.

List

List structures used for ordered collections.

Figure 17 shows all 36 object properties, 24 annotation properties and 3 data properties and their

hierarchies. The properties written in bold letters are the one that extends the SKOS-XL model to

SKOS-thes. Few examples of properties are as follows.

The object property ‘inScheme’ links a concept ‘MyConcept’ to concept scheme ‘MyScheme’. Written

in the Turtle syntax, the RDF triple looks like:

<MyConcept> skos:inScheme <MyScheme>

Object property ‘subordinateArray’ explicitly links a (superordinate) concept ‘MyConcept’ to one or

more subordinate arrays e.g. ‘MyArray’. Each array may either be composed of narrower concepts of

the superordinate concept or by concepts that need not be narrower concepts of the superordinate

concept. Written in the Turtle syntax, the RDF triple looks like:

<MyConcept> skos-thes:subordinateArray <MyArray >

Annotation property ‘description’ links a concept with its description composed of a string and an

optional language tag. Written in the Turtle syntax, the RDF triple looks like:

<MyConcept> terms:description ”Ability to response to a disaster.”@en

Data property ‘literalForm’ links a label <MyLabel>with its plain literal. Written in the Turtle syntax,

the RDF triple looks like:

<MyLabel> skosxl:literalForm "Medical aid"@en

Detailed descriptions and examples of the SKOS-thes classes and properties are published on the

web page[35].



www.episecc.eu

Figure 17: SKOS-thes object, annotation and data properties

The SKOS-thes model, besides the standard namespaces such as rdf, rdfs, owl and xsd, uses the

following namespaces for URIs:

iso-thes for identifiers used in SKOS-thes model, it is a prefix for URI

http://purl.org/iso25964/skos-thes#;

skos for identifiers used in SKOS model, it is a prefix for URI

http://www.w3.org/2004/02/skos/core#;

xl for identifiers used in SKOS-XL model, it is a prefix for URI

http://www.w3.org/2008/05/skos-xl #;

terms for identifiers used in Dublin Core model, it is a prefix for URI

terms="http://purl.org/dc/terms/.

The official website that publishes information on further development of the SKOS-thes model is

hosted by the National Information Standards Organisation (NISO), the TC46/SC9 Secretariat [38].

The above described SKOS-thes model is selected because it is a model applicable to store various

semantic structures such as vocabularies or thesauri and to establish and maintain mappings



www.episecc.eu

between them. Thus, the SKOS-thes model is recognised as a standard model for multiple thesauri.

SKOS-thes is further leveraged to satisfy the needs of the Semantic Repository what is described in

the sections that follows.

4.3.2. Introduction of SKOS-thes to the EPISECC project

SKOS-thes as a selected design pattern is introduced to the needs of the EPISECC Semantic

Repository. As described in the Section 4.1 and illustrated on the Figure 10, the Semantic Repository

as one structure will contain the following sub-structures:

EPISECC Taxonomy with time, space, units and selected generic concepts describing Earth

and environment from SWEET ontology,

CAP XML scheme,

EMSI data model with the codes,

emergency organisations’ semantic structures.

Also, the semantic relations between concepts from different sub-structures will be stored in the

Semantic Repository.

The process of SKOS-thes introduction consists of selection of the most adequate SKOS-thes

elements to represent the following:

the elements of Semantic Repository sub-structure,

the semantic relations between concepts from different sub-structures.

The following sections describe the above two processes of SKOS-thes introduction to the EPISECC

project.

4.3.2.1. Sub-structures elements in SKOS-thes

Table 6 shows the sub-structures elements and corresponding SKOS-thes elements. Every sub-

structure element will be represented by one or more SKOS-thes elements either class or property.

Some examples follows:

‘EPISECC Taxonomy’ is entered as an individual data item (hereinafter called individual), as a

member of SKOS-thes class Concept Scheme and having description defined by property

Description;

concept ‘Flood’ is entered as an individual, as a member of SKOS-thes class Concept and

belonging to the ‘EPISECC Taxonomy’ concept scheme;

term of concept ‘Flood’ is entered as an individual, as a member of SKOS-thes class Preferred

Term and linked with concept ‘Flood’ by property Has Preferred Label;

definition of concept ‘Flood’ is entered as an literal value defined by a property Description

concept ‘Flash flood’ and concept ‘Flood’ are related by property Broader;

concept ‘Position’ is entered as an individual, as a member of SKOS-thes class Concept and

belonging to the ‘EMSI’ concept scheme.



www.episecc.eu

Table 6: Representation of the sub-structures elements in SKOS-thes model

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)

Compound term Compound Equivalence (class)

Split Non Preferred Term (class)

Plus Use Term / Plus Used For Term (property)

CAP XML Scheme Message element Concept (class), Preferred Term (class)

Description (property)

Message sub-element Concept (class), Preferred Term (class)


Code value Concept (class), Preferred Term (class)


List of code values Collection (class), List (class)

EMSI data model and codes

Element group Concept (class), Preferred Term (class)


Element Concept (class), Preferred Term (class)


List of elements Collection (class), List (class)

Code Concept (class), Preferred Term (class)


Code elements Concept (class), Preferred Term (class)


Code hierarchy Narrower/Broader (property)



www.episecc.eu

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

(classes and properties)

GeoSPARQL vocabulary Class Concept (class), Preferred Term (class)


Individual Concept (class), Preferred Term (class)


Class hierarchy Narrower/Broader (property)

W3C time ontology Class Concept (class), Preferred Term (class)





Enumerated class Collection (class), List (class)

SWEET ontology Class Concept (class), Preferred Term (class)





QUDT ontology Class Concept (class), Preferred Term (class)





Selected emergency organisation

Concept Concept (class)

Definition Description (property)

Term Preferred Term (class)

Concept hierarchy Narrower/Broader (property)

The most complex representation is needed for facets and compound terms which are elements of

the EPISECC Taxonomy. The other semantic sub-structures will be represented by concepts,

definitions, terms and by narrower/broader properties in case the sub-structure includes the

hierarchy.



www.episecc.eu

4.3.2.2. Semantic relations in SKOS-thes

To semantically relate concepts from emergency organisations to the EPISECC Taxonomy and other

semantic sub-structures, the more subtle way of relating is needed other then 1:1 translation as

described in the Chapter 3. SKOS-thes model includes five semantic relations as five object

properties. Figure 18 shows the semantic relations as object properties and their hierarchy and

relations in the SKOS-thes model. Mapping Relation has super-property Semantic Relation and the

following sub-properties: Broad Match, Narrow Match, Close Match and Related Match. Close Match

has sub-property Exact Match. Broad Match and Narrow Match are mutually inverse properties. Also,

Broad and Narrow Match are sub-properties of Broader and Narrower properties respectively, and

Related Match is sub-property of Related property. It has an implication that when one concept is a

broad match of another it also implies that it is broader. The same apply for Narrow Match and

Narrow, and for Relate Match and Relate. As Exact Match is sub-property of Close Match, if one

concept is an exact match of another, it is also a close match of it. The semantic mapping match

relations are intended for mapping one semantic structure to another or when concepts are defined

separately but are semantically related.

Figure 18: Graph of the SKOS-thes semantic relations (adopted from [15])

Chapter 3 explains the semantic mapping process of the CIS sub-system called Semantic mapping.

Semantic mapping of concepts could be: translation or 1:1 mapping between concepts, advanced

translation if mapping between concepts is not restricted to 1:1 and a classification against taxonomy

structures. Table 7 describes the correspondence between semantic mapping needed in CIS and

SKOS-thes elements.



www.episecc.eu

Table 7: Representation of the CIS semantic mapping in SKOS-thes model

Semantic mapping in CIS SKOS-thes object

property SKOS-thes relation description

Translation or 1:1 Exact match Two concepts have the same meaning and

can be used interchangeably.

Advanced translation Exact match Two concepts have the same meaning and

can be used interchangeably.

Narrow match Hierarchical mapping between two concepts:

concept A has narrow match in Concept B if

A is more general concept than B.

Broad match Hierarchical mapping between two concepts:

concept A has broad match in Concept B if A

is more specific concept than B.

Close match Two concepts are sufficiently similar that

they can be used interchangeably in some

information retrieval applications.

Related match There is an associative mapping between

two concepts.

Classification Exact match* Concept A belongs to the class described by

Concept B.

Narrow match* Concept A has narrow match in Concept B if

A is more general concept than the class

described by Concept B.

Broad match* Concept A has broad match in Concept B if A

is more specific concept than the class

described by Concept B.

*concept can be a compound term created from taxonomy’s facets

Figure 19 shows the process of mapping relations between an emergency organisation and the

EPISECC Taxonomy. Semantic mapping performed in CIS includes only a classification. The figure

illustrates the Use-case 2 described in the Chapter 3 that is a process of entering semantic mappings

into the Semantic Repository. The Semantic mapping expert classifies emergency organisation's

concepts against the EPISECC Taxonomy’s concepts and assigns the SKOS-thes mapping relations to

the found relations. These semantic mappings are stored in the Semantic Repository.



www.episecc.eu

Figure 19: Semantic mapping with SKOS-thes relations

Two examples illustrated on the Figure 19 are as follows:

emergency organisation’s concept ‘Fire’ is exact match of the EPISECC Taxonomy concept

’Fire’;

emergency organisation’s concept ‘Water tank’ has broad match in the EPISECC Taxonomy

concept ’Specialised vehicle’.



www.episecc.eu

5. Data model testing

This chapter describes the first implementation and testing of Data model done in parallel with data

model design. A test database is created and loaded with data. Semantic mappings between

concepts of different sub-structures are inserted too. Data model testing included the following:

logical consistency of the test database is checked by applying reasoning algorithms;

semantic matching is tested by applying reasoning algorithms and use of SPARQL queries.

The test database is created with Protégé Desktop software already used for the EPISECC Taxonomy

development and the software description is given in the Deliverable 4.2. Protégé Desktop with its

advanced functions and plug-ins is used for the input of EPISECC Taxonomy and organisations’

concepts, graph visualisations, data search, reasoning and SPARQL queries. The Database is stored in

an OWL file locally on the computer in RDF/XML syntax. An excerpt from the test database is given in

Annex II. The second implementation and testing will be done through the Proof of concept and

validation and described in the Deliverable 6.3. The final Data model will be elaborated in Task 4.5.

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

5.1. Implementation in Protégé Desktop

The EPISECC Taxonomy is inserted to the test database accordingly to the SKOS-thes model

introduction described in the Chapter 4. Figure 20 shows a part of the directed graph of the SKOS-

thes model classes and the EPISECC Taxonomy concepts inserted as individuals. Every concept has an

identifier e.g. ‘epi00048’ and associated preferred label e.g. ‘Unavailable’. All concepts are members

of the class Concept what is defined by the rdf object property ‘type’ (illustrated with blue line on

Figure 20 called ‘has individual’).

Figure 20: The EPISECC Taxonomy concepts in the test database



www.episecc.eu

Figure 21 shows a part of the directed graph of the SKOS-thes model classes and the EPISECC

Taxonomy’s facets inserted as individuals. Every facet has an identifier e.g. ‘epi00044’ and associated

preferred label e.g. ‘Resource type’. All facets are members of the class Thesaurus Array what is

defined by the rdf object property ‘type’ (illustrated with blue line on Figure 22 called ‘has

individual’). ‘EPISECC’ individual represent the EPISECC Taxonomy as semantic sub-structure and thus

it is of type Concept Scheme. Object property ‘in Scheme’ defines that concepts and labels belong to

the EPISECC Taxonomy sub-structure.

Figure 21: The EPISECC Taxonomy facets in the test database

The EPISECC Taxonomy hierarchy is inserted by adding the properties ‘narrower’ between the

corresponding concepts. Facets are related to the super-concepts by property ‘subordinate Array’

and to the sub-concepts by property ‘member’. The compound terms are not inserted during the first

testing because that asks for end users involvement and opposing the EPISECC Taxonomy to their

concepts. The second implementation and testing in Tasks 6.1, 6.2 and 6.3 will include them as well.

Figure 22 and Figure 23 show the Protégé Desktop interface with inserted individuals and

corresponding annotation properties (e.g. Label and Description), object properties (e.g. Preferred

Labels, Has member) and assigned types/class (e.g. Thesaurus Array). The Protégé Desktop interface

allows individuals to be listed and sorted by different properties. On the Figure 22 individuals are

listed by identifiers while on the Figure 23 by labels.



www.episecc.eu

Figure 22: Protégé Desktop interface with individuals listed by identifiers

Figure 23: Protégé Desktop interface with individuals listed by labels

The test database passed the logical consistency check done by reasoning algorithms. The model is

logically consistent because the reasoning algorithm didn’t infer that one individual belongs to two

disjoint classes. That proofs the data is entered according to the rules imposed by the SKOS-thes

model. Also, that ensures no mapping ambiguity appears in the test database what is stressed in data

model requirements described in the Chapter 3.

An excerpt from the test database of the Semantic Repository is given in Annex II. It is an OWL file in

RDF/XML syntax containing one Concept Scheme, seven Thesaurus Arrays, 17 Concepts and 24

Preferred Terms.



www.episecc.eu

5.2. Testing of semantic mapping and matching by reasoning and use of SPARQL

After inserting the EPISECC Taxonomy into the test database, the testing of semantic mapping and

matching uses four steps:

adding concepts from two organisations in the test database;

semantic mapping: classifying each organisation’s concepts against the EPISECC Taxonomy’s

concepts, what means to assign mapping relation between the organisation’s concept and

the EPISECC Taxonomy’s concept and store it in the test database;

reasoning over the test database and inferring new semantic mappings;

semantic matching: querying the test database to derive semantic relations between

organisations’ concepts via the EPISECC Taxonomy concepts.

For the testing of semantic mapping and matching, the test database is enriched with concepts from

the EMSI data model and the Croatian 112 service. The test database contains the following:

3 sub-structures inserted as concepts schemes:

o the EPISECC Taxonomy as concept scheme with label ‘EPISECC’,

o EMSI data model as ‘EMSI message’ and

o Croatian 112 service as ‘CRO_SOP’;

23 facets inserted as collections and 97 concepts from the EPISECC Taxonomy and their

hierarchy;

62 EMSI data model concepts and their hierarchy;

25 Croatian 112 service concepts with labels in Croatian and English language.

Figure 24: Concepts from three sub-structures and with multilingual labels in the test database



www.episecc.eu

EMSI concepts are created based on the EMSI specifications and given examples [18] and Croatian

112 service concepts based on the Standard Operating Procedures [39]. Figure 24 shows part of

inserted concepts, their concepts schemes and labels in English and Croatian language.

Figure 25: Semantic mappings entered in the test database

EMSI concepts are classified to the EPISECC Taxonomy concepts e.g. EMSI concept ‘Actual’ has

broader EPISECC concept ‘In progress’. Also, the Croatian 112 service concepts are classified to the

EPISECC Taxonomy concepts e.g. ‘Požar’ has exact EPISECC concept ‘Fire’. Figure 25 shows part of

inserted semantic mappings against the EPISECC Taxonomy concepts.

Figure 26: Inserted and inferred relations in the test database



www.episecc.eu

Based on the inserted mappings and their properties (e.g. a property ‘exact match’ is transitive

property), new mappings could be inferred by the reasoning algorithm. Figure 26 shows inserted and

inferred relations in the test database.

After populating the test database with the inferred mappings, the semantic matching process uses

SPARQL queries to derive semantic relations between organisations concepts via the EPISECC

Taxonomy concepts. Figure 28 illustrates the semantic matching process on the example of two

concepts: ‘Decontamination’ from Organisation A and ‘Purification’ from Organisation B. Firstly, two

concepts were mapped/classified against the EPISECC Taxonomy concept ‘Decontamination’ with

exact and broader match respectively. Secondly, reasoning algorithm inferred the relation broader

match between ‘Decontamination’ from Organisation A and ‘Purification’ from Organisation B

concepts. Finally, SPQRQL query retrieved the semantic relation between the Organisation A and B

concepts.

Figure 27: Semantic matching process

Figure 28 and Figure 29 show two examples of the used SPARQL queries for the semantic matching

over the test database. Figure 28 shows the Protégé Desktop interface with entered SPARQL query

and its results: derived exact matches between EMSI and CRO_SOP concepts via EPISECC concepts.

Figure 29 shows Protégé Desktop interface with entered SPARQL query and its results: derived broad

matches between CRO_SOP and concepts via EPISECC concepts including notation of CRO_SOP

concepts on Croatian and English language.



www.episecc.eu

Figure 28: Exact match between EMSI and CRO_SOP concepts

Figure 29: Broad match between EMSI and CRO_SOP concepts

The above described testing of semantic mapping and matching has clearly shown a viability of the

designed processes and data model. The number of matched concepts depends only on richness of

the Semantic Repository with concepts and not on the design of processes and data.



www.episecc.eu

6. Conclusions and follow-up suggestions

The EPISECC Data model presented here is a result of the CIS design process and reflects the draft CIS

design, particularly the design of CIS sub-system called Semantic Mapping Service. The design

process started with an analysis of tools and data models used today in emergency management

across Europe (Deliverables 2.1, 2.2, 3.4 and 4.1) and as no tool or data model prevails, it is decided

to design the data model from the scratch. Thus, the Data model development could strive towards

the state-of-the-art technologies for the semantic interoperability.

The database role in the Semantic Mapping Service is to support processes of semantic mapping and

matching described in this deliverable. The concept of Semantic Repository is introduced as a

database component of the CIS and it is a central place where semantic descriptions will be stored

and used by software components of the CIS. This design decision has an important implication on

the overall CIS design because semantic descriptions became independent of tools and application

codes. Now, evolving semantic descriptions are maintained in a database and there are no needs for

upgrading tools every time semantics change. Semantic descriptions became data in a database.

Another important design decision is to use the RDF database model for the Semantic Repository.

While having a central place for the semantic descriptions in the CIS, the deployment of the RDF

database model made that central place distributed over the web. Semantic descriptions now can be

maintained by common effort of all CIS participants/users. They could be responsible for maintaining

of their semantic descriptions. Software developer efforts could be shifted from upgrading

application codes with new and always changing semantics to the development of services which will

utilise the Semantic Repository and improve semantic interoperability as a whole.

SKOS-thes model is reused and introduced to the needs of the CIS Semantic Repository. SKOS-thes is

based on two standards: the SKOS standard for representing knowledge over the computers network

and ISO 25964 standard for linked thesauri. This opens possibilities for future use of the Semantic

Repository by communities outside the CIS participants/users e.g. via Linked Open Vocabulary,

shared and linked open access vocabularies on the web [40].

The first implementation and testing is done in parallel with the design and it is described in this

deliverable. By use of the Protégé Desktop, a test database is developed and semantic mapping and

matching are successfully executed over the test database.

Further EPISECC Data model model implementation is foreseen in WP5 through the realisation of the

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

Data model validation will be done during proof of concept in WP6. Firstly, end users will enter their

concepts in the Semantic Repository and classify them to the EPISECC Taxonomy concepts and

secondly, they will create and exchange the messages. The results of will be processed in the Task 4.5

and elaborated in the Deliverable D4.5.together with the final data model description.



www.episecc.eu

Bibliography

[1] W3C, "RDF Schema 1.1", 2014. [Online]. Available: https://www.w3.org/TR/rdf-schema/.

[Accessed 09 05 2016].

[2] W3C, "OWL 2 Web Ontology Language Primer (Second Edition)", 2012. [Online]. Available:

https://www.w3.org/TR/2012/REC-owl2-primer-20121211/. [Accessed 09 05 2016].

[3] T. Berners Lee, J. Handler and O. Lassila, “The Semantic Web”, Scientific American, May, pp.

29-37, 2001.

[4] OGC, “GeoSPARQL - A Geographic Query Language for RDF Data”, 2012. [Online]. Available:

http://www.opengeospatial.org/standards/geosparql. [Accessed 09 05 2016].

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

[Accessed 09 05 2016].

[6] NASA, “SWEET ontology”, 2014. [Online]. Available: https://sweet.jpl.nasa.gov/. [Accessed 09

05 2016].

[7] TopQuadrant and NASA, “QUDT - Quantities, Units, Dimensions and Data Types Ontologies”,

2014. [Online]. Available: http://qudt.org/. [Accessed 09 05 2016].

[8] OASIS, “Common Alerting Protocol Version 1.2”, 2010. [Online]. Available: http://docs.oasis-

open.org/emergency/cap/v1.2/CAP-v1.2-os.html. [Accessed 09 05 2016].

[9] CWA 15931-1, “Disaster and emergency management - Shared situation awareness - Part 1:

Message structure”, 2009. [Online]. Available: https://www.oasis-

open.org/committees/download.php/42411/CWA_15931-1. [Accessed 09 05 2016].

[10] A. Isaac and J. De Smedt, “SKOS-thes”, 2015. [Online]. Available:

http://pub.tenforce.com/schemas/iso25964/skos-thes/. [Accessed 09 05 2016].

[11] S. Graeme and W. Graham, “Data Modeling Essentials”, Elsevier Science & Technology, 2005.

[12] D. Avison and G. Fitzgerald, “Information Systems Development: Methodologies, Techniques

and Tools”, McGraw-Hill Education, 2006.

[13] American National Standards Institute, “ANSI/X3/SPARC Study Group on Data Base

Management Systems - Interim Report”, 1975.

[14] M.C. Suárez de Figueroa, NeOn methodology for building ontology networks: specification,

scheduling and reuse, Dissertation, Madrid: Universidad Politécnica de Madrid, 2010.

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

[16] Stanford University School of Medicine, “Protégé”, 2016. [Online]. Available:

http://protege.stanford.edu/. [Accessed 09 05 2016].

[17] The Apache Software Foundation, “Apache Jena”, 2016. [Online]. Available:

https://jena.apache.org/index.html. [Accessed 09 05 2016].

[18] ISO/TR 22351, “Societal security — Emergency management — Message structure for

exchange of information", 2015.



www.episecc.eu

[19] European Commission, “European Interoperability Framework (EIF) for European public

services”, 2010. [Online]. Available:

http://ec.europa.eu/isa/documents/isa_annex_ii_eif_en.pdf. [Accessed 09 05 2016].

[20] Y.A. Bishr, “Overcoming the semantic and other barriers to GIS interoperability”,

International journal of geographic Information Science, Vol.12, No.4, pp. 299-314, 1998.

[21] H. Pundt and Y. Bishr, “Domain Ontologies for Data Sharing – An Example from

Environmental Monitoring Using Field GIS”, Computer & Geosciences, Vol.28, No.1, pp. 95-

102, 2002.

[22] T.R. Gruber, “A translation approach to portable ontologies”, Knowledge Acquisition, Vol.5,

No.2, pp. 199-220, 1993.

[23] W3C, “Semantic web”, 2016. [Online]. Available:

https://www.w3.org/standards/semanticweb/. [Accessed 09 05 2016].

[24] S. Bratt, ”Semantic Web, and Other Technologies to Watch”, Presentation, 2007. [Online].

Available: https://www.w3.org/2007/Talks/0130-sb-W3CTechSemWeb/#(1). [Accessed 09 05

2016].

[25] W3C, “Standards”, 2016. [Online]. Available: https://www.w3.org/. [Accessed 09 05 2016].

[26] W3C, “Resource Description Framework”, 2014. [Online]. Available:

https://www.w3.org/RDF. [Accessed 09 05 2016].

[27] F. Baader and W. Nutt, “Basic description logics”, “The description logic handbook: theory,

implementation, and applications”, F. Baader, D.L. McGuinness, D. Nardi et al (Editors),

Cambridge University Press, pp. 47-100, 2003.

[28] W3C, “RDF 1.1 N-Triples”, 2014. [Online]. Available: https://dvcs.w3.org/hg/rdf/raw-

file/default/rdf-turtle/n-triples.html. [Accessed 09 05 2016].

[29] W3C, “RDF 1.1 Turtle”, 2014. [Online]. Available: https://www.w3.org/TR/turtle/. [Accessed

09 05 2016].

[30] W3C, “RDF 1.1 XML Syntax”, 2014. [Online]. Available: https://www.w3.org/TR/rdf-syntax-

grammar/. [Accessed 09 05 2016].

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

https://www.w3.org/2004/02/skos/. [Accessed 09 05 2016].

[32] FAO, “AGROVOC Multilingual agricultural thesaurus”, 2016. [Online]. Available:

http://aims.fao.org/vest-registry/vocabularies/agrovoc-multilingual-agricultural-thesaurus.

[Accessed 09 05 2016].

[33] European Commission, “EuroVoc, the EU's multilingual thesaurus”, 2016. [Online]. Available:

http://eurovoc.europa.eu/. [Accessed 09 05 2016].

[34] W3C, “SKOS Simple Knowledge Organisation System eXtension for Labels (SKOS-XL)”, 2009.

[Online]. Available: http://www.w3.org/2008/05/skos-xl. [Accessed 09 05 2016].

[35] A. Isaac and J. De Smedt, “SKOS-thes RDF Schema”, 2015. [Online]. Available:

http://eelst.cs.unibo.it/apps/LODE/source?url=http://purl.org/iso25964/skos-thes.

[Accessed 09 05 2016].



www.episecc.eu

[36] NISO, “ISO 25964 – the international standard for thesauri and interoperability with other

vocabularies”, 2016. [Online]. Available: http://www.niso.org/schemas/iso25964/. [Accessed

09 05 2016].

[37] ISO TC46/SC9/WG8 working group and A. Isaac, “Correspondence between ISO 25964 and

SKOS/SKOS‐XL Models”, 2013. . [Online]. Available:

http://www.niso.org/apps/group_public/download.php/12351/Correspondence%20ISO2596

4-SKOSXL-MADS-2013-12-11.pdf. [Accessed 09 05 2016].

[38] NISO, “Interoperability with SKOS and other schemas”, 2016. [Online]. Available:

http://www.niso.org/schemas/iso25964/#skos. [Accessed 09 05 2016].

[39] Koprivnica Križevci County, “Plan zaštite od požara i tehnološke eksplozije Koprivničko-

križevačke županije”, Koprivnica, Croatia, 2012.

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

http://lov.okfn.org/dataset/lov. [Accessed 09 05 2016].



www.episecc.eu

Annex

I. SKOS-thes data model

SKOS-thes model below is RDF file downloaded from the web page [35].

<?xml version="1.0"?>

<rdf:RDF xmlns:iso-thes="http://purl.org/iso25964/skos-thes#" xml:base="http://purl.org/iso25964/skos-thes"

xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"

xmlns:xl="http://www.w3.org/2008/05/skos-xl#"

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#"

xmlns:dcterms="http://purl.org/dc/terms/" xmlns:voaf="http://purl.org/vocommons/voaf#"

xmlns:vs="http://www.w3.org/2003/06/sw-vocab-status/ns#" xmlns:foaf="http://xmlns.com/foaf/0.1/">

<owl:Ontology rdf:about="http://purl.org/iso25964/skos-thes">

<rdfs:comment xml:lang="en">These notes apply to the published mapping between the ISO 25964 data model and the SKOS schema (http://www.niso.org/schemas/iso25964/correspondencesSKOS/).

Remarks can be exchanged using: [email protected]

Subscription info and archive is on: http://www.niso.org/lists/25964info/

General information about ISO 25964: http://www.niso.org/schemas/iso25964/

The annotation http://www.w3.org/2003/06/sw-vocab-status/ns#term_status indicates "proposed" properties that are not part of the mapping documentation.</rdfs:comment>

<voaf:toDoList>Todo:

Not modelled but requiring further extension:

- CustomTermAttribute :

Best practice would be to define custom RDF data-type properties taking plain literal values. The property name depends on the customAttributeType.

- CustomConceptAttribute :

Best practice would be to define custom RDF data-type properties taking plain literal values. The property name depends on the customAttributeType.

- refersTo (reference from within a note to a concept or label/term:

May be an embedded and tagged link in the note value (e.g., as done for EuroVoc http://eurovoc.europa.eu/).

- CustomNote :

Depending noteType a new custom property should be defined as a sub-property of skos:note (consider applicability of: skos:changeNote and skos:example)

- BTG/NTG - BTP/NTP - BTI/NTI :

Currently these are only defined as direct (one-step) sub-properties of skos:broader / skos:narrower.

Some constraints currently expressed only in natural language (in rdfs:comment) may be formally expressed as OWL(2) axioms.

We have postponed the implementation of the iso-thes properties mentioned in the VersionHistory section of the


www.episecc.eu

mapping documentation.</voaf:toDoList>

<rdfs:seeAlso rdf:resource="http://www.niso.org/schemas/iso25964/correspondencesSKOS/"/>

<owl:imports rdf:resource="http://www.w3.org/2004/02/skos/core"/>

<owl:imports rdf:resource="http://www.w3.org/2008/05/skos-xl"/>

<dcterms:created rdf:datatype="http://www.w3.org/2001/XMLSchema#date">2013-10-04</dcterms:created>

<dcterms:modified rdf:datatype="http://www.w3.org/2001/XMLSchema#date">2015-03-17</dcterms:modified>

<dc:date rdf:datatype="http://www.w3.org/2001/XMLSchema#date">2015-03-17</dc:date>

<dcterms:creator foaf:name="Johan De Smedt"/>

<dcterms:creator foaf:name="Antoine Isaac"/>

<dcterms:contributor foaf:name="Stella Dextre Clarke"/>

<dcterms:contributor foaf:name="Jutta Lindenthal"/>

<dcterms:contributor foaf:name="Marcia Lei Zeng"/>

<dcterms:contributor foaf:name="Douglas S. Tudhope"/>

<dcterms:contributor foaf:name="Leonard Will"/>

<dcterms:contributor foaf:name="Vladimir Alexiev"/>

</owl:Ontology>







<owl:ObjectProperty rdf:about="http://purl.org/iso25964/skos-thes#narrowerInstantial">

<vs:term_status rdf:datatype="http://www.w3.org/2001/XMLSchema#string">proposed</vs:term_status>

<rdfs:label xml:lang="en">narrower term (instantial)</rdfs:label>

<skos:definition xml:lang="en">Definition: ISO 25964-1: NTI

The immediate (direct or one-step) class - instance relationship.</skos:definition>

<skos:changeNote xml:lang="en">The URI has been renamed: #narrowerInstantive is replaced by #narrowerInstantial according to the observed usage of these words in English. (2013-12-09)</skos:changeNote>

<rdfs:isDefinedBy rdf:resource="http://purl.org/iso25964/skos-thes"/>

<rdfs:subPropertyOf rdf:resource="http://www.w3.org/2004/02/skos/core#narrower"/>

<rdfs:domain rdf:resource="http://www.w3.org/2004/02/skos/core#Concept"/>

<rdfs:range rdf:resource="http://www.w3.org/2004/02/skos/core#Concept"/>

<owl:inverseOf rdf:resource="http://purl.org/iso25964/skos-thes#broaderInstantial"/>


</owl:ObjectProperty>



<owl:ObjectProperty rdf:about="http://purl.org/iso25964/skos-thes#broaderInstantial">


<rdfs:label xml:lang="en">broader term (instantial)</rdfs:label>

<skos:definition xml:lang="en">Definition: ISO 25964-1: BTI

www.episecc.eu

The immediate (direct or one-step) instance - class relationship.</skos:definition>

<skos:changeNote xml:lang="en">The URI has been renamed: #broaderInstantive is replaced by #broaderInstantial according to the observed usage of these words in English. (2013-12-09)</skos:changeNote>


<rdfs:subPropertyOf rdf:resource="http://www.w3.org/2004/02/skos/core#broader"/>







<owl:ObjectProperty rdf:about="http://purl.org/iso25964/skos-thes#narrowerGeneric">


<rdfs:label xml:lang="en">narrower term (generic)</rdfs:label>

<skos:definition xml:lang="en">Definition: ISO 25964-1: NTG

The immediate (direct or one-step) class - specialized class relationship.</skos:definition>





<owl:inverseOf rdf:resource="http://purl.org/iso25964/skos-thes#broaderGeneric"/>





<owl:ObjectProperty rdf:about="http://purl.org/iso25964/skos-thes#broaderGeneric">


<rdfs:label xml:lang="en">broader term (generic)</rdfs:label>

<skos:definition xml:lang="en">Definition: ISO 25964-1: BTG

The immediate (direct or one-step) class - generalized class relationship.</skos:definition>









<owl:ObjectProperty rdf:about="http://purl.org/iso25964/skos-thes#narrowerPartitive">


<rdfs:label xml:lang="en">narrower term (partitive)</rdfs:label>

<skos:definition xml:lang="en">Definition: ISO 25964-1: NTP

When the ISO 25964 standard is followed, the BTP/NTP relationship should qualify for a transitive closure.</skos:definition>

<skos:example xml:lang="en">A "bicycle wheel" for instance belongs uniquely to a "bicycle" while a "wheel" does not.

A BTP/NTP relationship should not be established between "bicycles" and "wheels" because a wheel could be part of a motor car, a wheelbarrow or one of many other artefacts.</skos:example>

www.episecc.eu

<owl:inverseOf rdf:resource="http://purl.org/iso25964/skos-thes#broaderPartitive"/>





<owl:ObjectProperty rdf:about="http://purl.org/iso25964/skos-thes#broaderPartitive">


<rdfs:label xml:lang="en">broader term (partitive)</rdfs:label>

<skos:definition xml:lang="en">Definition: ISO 25964-1: BTP

When the ISO 25964 standard is followed, the BTP/NTP relationship should qualify for a transitive closure.</skos:definition>

<skos:example xml:lang="en">A "bicycle wheel" for instance belongs uniquely to a "bicycle" while a "wheel" does not.

A BTP/NTP relationship should not be established between "bicycles" and "wheels" because a wheel could be part of a motor car, a wheelbarrow or one of many other artefacts.</skos:example>









<owl:ObjectProperty rdf:about="http://purl.org/iso25964/skos-thes#plusUF">

<vs:term_status rdf:datatype="http://www.w3.org/2001/XMLSchema#string">released</vs:term_status>

<rdfs:label xml:lang="en">split non preferred term</rdfs:label>

<skos:definition xml:lang="en">Definition: ISO 25964-1: UF+

The non preferred term labeling a complex concept.

The complex concept will be identified by splitting the non preferred term into 2 or more (component) preferred terms.</skos:definition>


<rdfs:domain rdf:resource="http://purl.org/iso25964/skos-thes#CompoundEquivalence"/>

<rdfs:range rdf:resource="http://purl.org/iso25964/skos-thes#SplitNonPreferredTerm"/>





<owl:ObjectProperty rdf:about="http://purl.org/iso25964/skos-thes#plusUFTerm">


<rdfs:label xml:lang="en">UF+</rdfs:label>

<skos:definition xml:lang="en">Definition: ISO 25964-1: UF+

The non-preferred term expressing a compound concept that should be represented by a combination of preferred terms</skos:definition>


<rdfs:range rdf:resource="http://purl.org/iso25964/skos-thes#SplitNonPreferredTerm"/>

<rdfs:domain rdf:resource="http://purl.org/iso25964/skos-thes#PreferredTerm"/>

<owl:inverseOf rdf:resource="http://purl.org/iso25964/skos-thes#plusUseTerm"/>

<rdfs:subPropertyOf rdf:resource="http://www.w3.org/2008/05/skos-xl#labelRelation"/>





<owl:ObjectProperty rdf:about="http://purl.org/iso25964/skos-thes#plusUse">

www.episecc.eu


<rdfs:label xml:lang="en">component preferred term</rdfs:label>

<skos:scopeNote xml:lang="en">ISO 25964-1: USE+

One of two or more (component) preferred terms used together to represent the (complex) concept labeled by a (split) non preferred term.</skos:scopeNote>


<rdfs:domain rdf:resource="http://purl.org/iso25964/skos-thes#CompoundEquivalence"/>

<rdfs:range rdf:resource="http://purl.org/iso25964/skos-thes#PreferredTerm"/>





<owl:ObjectProperty rdf:about="http://purl.org/iso25964/skos-thes#plusUseTerm">


<rdfs:label xml:lang="en">USE+</rdfs:label>

<skos:definition xml:lang="en">Definition: ISO 25964-1: USE+

The two or more (component) preferred terms following should be used together to represent the concept indicated by the (split) non preferred term.</skos:definition>

<skos:scopeNote xml:lang="en">iso-thes:plusUseTerm (and its inverse iso-thes:plusUFTerm) may be derived from iso-thes:CompoundEquivalence.

For an iso-thes:CompoundEquivalence instance each derived iso-thes:plusUseTerm has as:

- subject: the iso-thes:plusUF value

- object: the iso-thes:plusUse value

In special cases where the iso-thes:SplitNonPreferredTerm has more than one decomposition, the inverse inference may not be possible.

</skos:scopeNote>


<rdfs:range rdf:resource="http://purl.org/iso25964/skos-thes#PreferredTerm"/>

<rdfs:domain rdf:resource="http://purl.org/iso25964/skos-thes#SplitNonPreferredTerm"/>

<rdfs:subPropertyOf rdf:resource="http://www.w3.org/2008/05/skos-xl#labelRelation"/>





<owl:ObjectProperty rdf:about="http://purl.org/iso25964/skos-thes#subGroup">


<rdf:type rdf:resource="http://www.w3.org/2002/07/owl#TransitiveProperty"/>

<rdfs:label xml:lang="en">sub group</rdfs:label>

<skos:definition xml:lang="en">Definition: All members of the (object) subGroup are members of the (subject) group.</skos:definition>


<rdfs:range rdf:resource="http://purl.org/iso25964/skos-thes#ConceptGroup"/>

<rdfs:domain rdf:resource="http://purl.org/iso25964/skos-thes#ConceptGroup"/>

<owl:inverseOf rdf:resource="http://purl.org/iso25964/skos-thes#superGroup"/>





<owl:ObjectProperty rdf:about="http://purl.org/iso25964/skos-thes#subordinateArray">

www.episecc.eu

<rdfs:label xml:lang="en">subordinate array</rdfs:label>

<skos:definition xml:lang="en">Definition: Explicitly links a (superordinate) concept to one or more subordinate arrays. Each array may either be composed of narrower concepts of the superordinate concept (in which case there may be an associated node label with a characteristic of division) or by concepts that need not be narrower concepts of the superordinate concept (in which case a node label may provide a facet name).

In other words, though each array only contains sibling concepts, no hierarchical relation may be automatically derived between a concept and the concepts in any of its subordinate arrays. The hierarchical relationship between these concepts has to be asserted explicitly.</skos:definition>


<rdfs:range rdf:resource="http://purl.org/iso25964/skos-thes#ThesaurusArray"/>






<owl:AnnotationProperty rdf:about="http://www.w3.org/2003/06/sw-vocab-status/ns#term_status">

<rdfs:label xml:lang="en">model axiom or term status</rdfs:label>


<dcterms:issued rdf:datatype="http://www.w3.org/2001/XMLSchema#date">2013-12-05</dcterms:issued>


<rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/>

<rdfs:isDefinedBy rdf:resource="http://www.w3.org/2003/06/sw-vocab-status/ns"/>

</owl:AnnotationProperty>



<owl:ObjectProperty rdf:about="http://purl.org/iso25964/skos-thes#superGroup">


<rdf:type rdf:resource="http://www.w3.org/2002/07/owl#TransitiveProperty"/>

<rdfs:label xml:lang="en">super group</rdfs:label>

<skos:definition xml:lang="en">Definition: All members of the (subject) group are members of the (object) superGroup.</skos:definition>



<rdfs:range rdf:resource="http://purl.org/iso25964/skos-thes#ConceptGroup"/>





<owl:ObjectProperty rdf:about="http://purl.org/iso25964/skos-thes#superOrdinate">


<rdfs:label xml:lang="en">super ordinate</rdfs:label>

<skos:definition xml:lang="en">Definition: ISO 25964: hasSuperOrdinateConcept

The (subject) array organizes a set of sibling concepts under the (object) concept.</skos:definition>


<owl:inverseOf rdf:resource="http://purl.org/iso25964/skos-thes#subordinateArray"/>

<rdfs:domain rdf:resource="http://purl.org/iso25964/skos-thes#ThesaurusArray"/>

www.episecc.eu

<owl:ObjectProperty rdf:about="http://purl.org/iso25964/skos-thes#microThesaurusOf">


<rdfs:label xml:lang="en">micro-thesaurus of</rdfs:label>

<skos:definition xml:lang="en">Definition: Concept groups published as sub-thesauri (e.g., having micro-thesaurus as ISO conceptGroupType) </skos:definition>


<rdfs:subPropertyOf rdf:resource="http://www.w3.org/2004/02/skos/core#inScheme"/>


<rdfs:range rdf:resource="http://www.w3.org/2004/02/skos/core#ConceptScheme"/>







<owl:DatatypeProperty rdf:about="http://purl.org/iso25964/skos-thes#status">


<rdfs:label xml:lang="en">status</rdfs:label>

<rdfs:comment xml:lang="en">ISO status

- on ThesaurusConcept

- on ThesaurusTerm</rdfs:comment>


<rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/>

<rdfs:domain>

<owl:Class>

<owl:unionOf rdf:parseType="Collection">

<rdf:Description rdf:about="http://www.w3.org/2004/02/skos/core#Concept"/>

<rdf:Description rdf:about="http://www.w3.org/2008/05/skos-xl#Label"/>

</owl:unionOf>

</owl:Class>

</rdfs:domain>


</owl:DatatypeProperty>





<owl:Class rdf:about="http://purl.org/iso25964/skos-thes#CompoundEquivalence">


<rdfs:label xml:lang="en">Compound Equivalence</rdfs:label>

www.episecc.eu

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="http://purl.org/iso25964/skos-thes#plusUse"/>

<owl:onClass rdf:resource="http://purl.org/iso25964/skos-thes#PreferredTerm"/>

<owl:minQualifiedCardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#nonNegativeInteger">2</owl:minQualifiedCardinality>

</owl:Restriction>

</rdfs:subClassOf>

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="http://purl.org/iso25964/skos-thes#plusUF"/>

<owl:onClass rdf:resource="http://purl.org/iso25964/skos-thes#SplitNonPreferredTerm"/>

<owl:qualifiedCardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#nonNegativeInteger">1</owl:qualifiedCardinality>

</owl:Restriction>

</rdfs:subClassOf>

<rdfs:comment xml:lang="en">ISO CompoundEquivalence

iso-thes:plusUseTerm (and its inverse iso-thes:plusUFTerm) may be derived from iso-thes:CompoundEquivalence.

For a iso-thes:CompoundEquivalence instance each derived iso thes:plusUseTerm has as:

- subject: the iso thes:plusUF value

- object: the iso thes:plusUse value

An ISO 25964 compliant thesaurus only has one compound equivalence relation for each split non preferred term.

In special cases where the iso-thes:SplitNonPreferredTerm has more than one decomposition, the inverse inference may not be possible. (While this situation should not arise within a single thesaurus that complies with ISO 25964, it could occur if terms and relationships have been drawn from more than one thesaurus. For this reason the property skos:inScheme (http://www.w3.org/2004/02/skos/core#inScheme) should be used with each instance of the class Compound Equivalence, to relate it to its Thesaurus.)</rdfs:comment>



</owl:Class>



<owl:Class rdf:about="http://purl.org/iso25964/skos-thes#ConceptGroup">


<rdfs:label xml:lang="en">Concept Group</rdfs:label>

<rdfs:subClassOf rdf:resource="http://www.w3.org/2004/02/skos/core#Collection"/>

<owl:disjointWith rdf:resource="http://purl.org/iso25964/skos-thes#ThesaurusArray"/>

<rdfs:comment xml:lang="en">ISO ConceptGroup

Concept groups have several applications.

One such application is illustrated by the EUROVOC and the UNESCO thesaurus. Both of these use a super structure of domain and of micro-thesaurus. Both of these structuring elements can be modeled using ConceptGroup.</rdfs:comment>

<skos:definition xml:lang="en">Definition: A concept group is a group of concepts making up a subset of the thesaurus. Member concepts may be drawn from many different facets or hierarchies of the thesaurus. While almost any criterion may be used to select the members, this construct is commonly used to define a micro-thesaurus that will be used by a particular user group or domain.

www.episecc.eu

The skos:inScheme (http://www.w3.org/2004/02/skos/core#inScheme) property should be used to indicate the thesaurus to which an instance of skos:Collection applies (see ISO 25964: isPartOf).

Use rdfs:label or xl:prefLabel for the ConceptGroup label (1 per language).

Optional label attributes typically are mapped to dc: (or dct:) properties:

- dct:created

- dct:modified

These can be attached to the xl:Label instance that is the value of the xl:prefLabel.

Depending on the value of the ISO conceptGroupType a sub-class of iso thes:ConceptGroup should be defined.

e.g.: EUROVOC and UNESCO use

- Domain

- MicroThesaurus (an iso-thes:hasSubGroup of a Domain)</skos:definition>



</owl:Class>



<owl:Class rdf:about="http://purl.org/iso25964/skos-thes#PreferredTerm">


<rdfs:label xml:lang="en">Preferred Term</rdfs:label>

<rdfs:subClassOf rdf:resource="http://www.w3.org/2008/05/skos-xl#Label"/>

<rdfs:comment xml:lang="en">ISO PreferredTerm:

Instances of iso-thes:PreferredTerm are objects of skos-xl:prefLabel statements.

Making the class explicit allows RDF/OWL consistency checks for CompoundEquivalence.</rdfs:comment>



</owl:Class>



<owl:Class rdf:about="http://purl.org/iso25964/skos-thes#SimpleNonPreferredTerm">


<rdfs:label xml:lang="en">Simple Non Preferred Term</rdfs:label>


<rdfs:comment xml:lang="en">ISO SimpleNonPreferredTerm

Instances of iso:SimpleNonPreferredTerm are the object of either of skos xl:altLabel or skos xl:hiddenLabel statements.

Identifying cases of Equivalence:

In SKOS/-XL, Equivalence may be derived between the skos/skos xl:prefLabel statements on one hand and the skos/skos xl:altLabel or the skos/skos xl:hiddenLabel statements on the other hand where:

- the subject of all these statements is the same instance of skos:Concept,

- the language of all the bound labels is the same,

- the prefLabel has the role USE, and

- the altLabel and hiddenLabel have the role UF.</rdfs:comment>



</owl:Class>

www.episecc.eu



<owl:Class rdf:about="http://purl.org/iso25964/skos-thes#SplitNonPreferredTerm">


<rdfs:label xml:lang="en">Split Non Preferred Term</rdfs:label>


<rdfs:comment xml:lang="en">iso SplitNonPreferredTerm

This class provides for an 'imagined' concept that may exist in a user’s mind but is not present in the thesaurus (Concept Scheme); it can, however, be represented by a combination of two or more preferred terms (skos-xl:prefLabel) in the thesaurus. (In contrast, concepts present in the thesaurus are provided for by the ThesaurusConcept class.)

This label is provided by the object property iso thes:plusUF

- domain: iso-thes:CompoundEquivalence

- range: iso-thes:SplitNonPreferredTerm.</rdfs:comment>



</owl:Class>



<owl:Class rdf:about="http://purl.org/iso25964/skos-thes#ThesaurusArray">


<rdfs:label xml:lang="en">Thesaurus Array</rdfs:label>

<rdfs:subClassOf rdf:resource="http://www.w3.org/2004/02/skos/core#Collection"/>

<skos:definition xml:lang="en">Definition: ISO ThesaurusArray

An array is a group of sibling concepts

Instances of ThesaurusArray can be mapped to instances of skos:OrderedCollection (a subclass of skos:Collection) if and only if the array needs to be an ordered array (in the ISO-25964 model the value of its Boolean attribute "ordered" is true).

It is advised to use the skos:inScheme (http://www.w3.org/2004/02/skos/core#inScheme) property on such a skos:Collection to relate it to its Thesaurus (see ISO 25964: isPartOf).

Concepts in a thesaurus array are sibling concepts in the thesaurus.

If present, the node label of a thesaurus array is mapped to rdfs:label or xl:prefLabel.

Optional node label attributes typically are mapped to dc: (or dct:) properties:

- dct:created

- dct:modified

These can be attached (if needed) to the xl:Label instance that is the value of xl:prefLabel.</skos:definition>



</owl:Class>



<rdf:Description>

<rdf:type rdf:resource="http://www.w3.org/2002/07/owl#AllDisjointClasses"/>

<owl:members rdf:parseType="Collection">

www.episecc.eu

<rdf:Description rdf:about="http://purl.org/iso25964/skos-thes#PreferredTerm"/>

<rdf:Description rdf:about="http://purl.org/iso25964/skos-thes#SimpleNonPreferredTerm"/>

<rdf:Description rdf:about="http://purl.org/iso25964/skos-thes#SplitNonPreferredTerm"/>

</owl:members>


</rdf:Description>





<rdf:Description rdf:about="http://www.w3.org/2004/02/skos/core#note">

<rdfs:comment xml:lang="en">ISO refersTo is not mapped.

Work is ongoing in the RDF group to type the content explicitly as HTML or XML in RDF1.1 (http://dvcs.w3.org/hg/rdf/raw-file/default/rdf-concepts/index.html#section-html). This would allow embedding relevant hyperlinks in notes.

May be an embedded and tagged link in the note value (e.g., as done for EuroVoc).

In ISO 25964, some types of Note are associated with concepts, others with terms. In SKOS, all documentation notes are associated with concepts.

In basic SKOS, notes are represented using simple annotation properties, which type captures the note type. However the SKOS annotation properties can also be used with structured representation of notes as fully-fledged resources. See http://www.w3.org/TR/skos-primer/#secdocumentation and http://www.w3.org/TR/skos-primer/#secadvanceddocumentation for examples of both approaches.

Within a thesaurus the application of notes to concept and term is more restrictive than in SKOS.

A note may have some structure or formatting. In general, this can be modelled using rdf:value (to represent lexicalValue)

The language should be held in rdf:value. If this is an XMLLiteral, the language shall also be made available using dc:language (or dct:language).

Note: Work is ongoing in the RDF group to type the content explicitly as HTML or XML In RDF1.1 (http://dvcs.w3.org/hg/rdf/raw-file/default/rdf-concepts/index.html#section-html). This would allow embedding relevant hyperlinks in notes.

Additional attributes can be added to the note structure:

- dct:created

- dct:modified</rdfs:comment>

</rdf:Description>



<rdf:Description rdf:about="http://www.w3.org/2004/02/skos/core#definition">

<skos:definition xml:lang="en">Caution: In ISO 25964, "hasDefinition" applies to a term rather than to a concept.</skos:definition>

</rdf:Description>

www.episecc.eu



<rdf:Description rdf:about="http://www.w3.org/2004/02/skos/core#editorialNote">

<skos:definition xml:lang="en">Caution: In ISO 25964, "hasEditorialNote" applies to a term rather than to a concept.</skos:definition>

</rdf:Description>

<rdf:Description rdf:about="http://www.w3.org/2004/02/skos/core#historyNote">

<skos:definition xml:lang="en">Definition: In ISO 25964, "hasHistoryNote" can apply to a term or to a concept.</skos:definition>

</rdf:Description>



<rdf:Description rdf:about="http://www.w3.org/2004/02/skos/core#scopeNote">

<skos:definition xml:lang="en">Caution: In ISO 25964, "hasScopeNote" applies to a concept rather than to a term.</skos:definition>

</rdf:Description>

<rdf:Description rdf:about="http://www.w3.org/2004/02/skos/core#notation">

<rdfs:comment xml:lang="en">Best practice in SKOS is to (RDF) type the notation value object. This allows multiple notation value types for the same concept or term to be distinguished.

Note: In ISO 25964-1, such typing is implicit in the thesaurus or it is part of the "notation" value.</rdfs:comment>

</rdf:Description>

<rdf:Description rdf:about="http://www.w3.org/2004/02/skos/core#prefLabel">

<rdfs:comment xml:lang="en">Simple super property of ISO hasPreferredLabel

Basic SKOS allows labels (as simple literals) to be attached directly to Concepts using skos:prefLabel; this is the preferred simple scenario where label relations are not explicit.</rdfs:comment>

</rdf:Description>

<rdf:Description rdf:about="http://www.w3.org/2004/02/skos/core#altLabel">

<rdfs:comment xml:lang="en">Simple or basic super property of ISO hasNonPreferredLabel

Applies if the value of "hasNonPreferredLabel" is of class SimpleNonPreferredTerm with the Boolean attribute "hidden" either absent or with value false.</rdfs:comment>

</rdf:Description>

<rdf:Description rdf:about="http://www.w3.org/2004/02/skos/core#hiddenLabel">

<rdfs:comment xml:lang="en">Simple or basic super property of ISO hasNonPreferredLabel

Applies if the value of "hasNonPreferredLabel" is of class SimpleNonPreferredTerm with the Boolean attribute "hidden" having value true.</rdfs:comment>

</rdf:Description>

<rdf:Description rdf:about="http://www.w3.org/2008/05/skos-xl#prefLabel">

<rdfs:comment xml:lang="en">Complex super property of ISO hasPreferredLabel

When a label is represented as skos xl:Label, a skos:prefLabel statement is derived from the skos-xl:prefLabel one. (Likewise for altLabel and hiddenLabel.)</rdfs:comment>

</rdf:Description>

<rdf:Description rdf:about="http://www.w3.org/2008/05/skos-xl#altLabel">

<rdfs:comment xml:lang="en">Complex super property of ISO hasNonPreferredLabel

Applies if the value of "hasNonPreferredLabel" is of class SimpleNonPreferredTerm with the Boolean attribute "hidden" either absent or with value false.</rdfs:comment>

</rdf:Description>

<rdf:Description rdf:about="http://www.w3.org/2008/05/skos-xl#hiddenLabel">

<rdfs:comment xml:lang="en">Complex super property of ISO hasNonPreferredLabel

Applies if the value of "hasNonPreferredLabel" is of class SimpleNonPreferredTerm with the Boolean

www.episecc.eu

attribute "hidden" having value true.</rdfs:comment>

</rdf:Description>

<rdf:Description rdf:about="http://www.w3.org/2004/02/skos/core#broader">

<skos:definition xml:lang="en">Comment: As an extension to SKOS, sub-properties of skos:broader and skos:narrower may be needed to model the different hierarchical relationships identified by the ISO 25964 attribute "role".</skos:definition>

</rdf:Description>

<rdf:Description rdf:about="http://www.w3.org/2004/02/skos/core#narrower">

<skos:definition xml:lang="en">Comment: As an extension to SKOS, sub-properties of skos:broader and skos:narrower may be needed to model the different hierarchical relationships identified by the ISO 25964 attribute "role".</skos:definition>

</rdf:Description>

<rdf:Description rdf:about="http://www.w3.org/2004/02/skos/core#related">

<skos:definition xml:lang="en">Comment: As an extension to SKOS, sub-properties of skos:related may be needed to model the different associative relationships identified by the ISO 25964 attribute "role".</skos:definition>

</rdf:Description>

<rdf:Description rdf:about="http://www.w3.org/2004/02/skos/core#broaderTransitive">

<rdfs:comment xml:lang="en">Can be used to derive ISO hasTopConcept (which is different from skos:hasTopConcept).

The ISO hasTopConcept can be derived in SKOS from skos:broaderTransitive where the object of skos:broaderTransitive is a concept having the property skos:topConceptOf (i.e., a ThesaurusConcept having topConcept = true).</rdfs:comment>

</rdf:Description>

<rdf:Description rdf:about="http://www.w3.org/2004/02/skos/core#narrowerTransitive">

<rdfs:comment xml:lang="en">Can be used to derive ISO isTopConceptOf (which is different from skos:isTopConceptOf).

The ISO isTopConceptOf can be derived in SKOS from skos:narrowerTransitive where the skos:narrowerTransitive has as subject a concept that is object of a skos:hasTopConcept statement (i.e., a ThesaurusConcept having topConcept = true).</rdfs:comment>

</rdf:Description>



<rdf:Description rdf:about="http://www.w3.org/2004/02/skos/core#inScheme">

<rdfs:comment xml:lang="en">Super property of ISO isPartOf

Applies to any ISO 25964 "isPartOf" relation that targets the Thesaurus. Subjects of the skos:inScheme statements can be ISO 25964’s ThesaurusConcept, ConceptGroup, and ThesaurusArray.

Only applies to ISO 25964 "contains" statements having a Thesaurus [ConceptScheme] as subject.</rdfs:comment>

</rdf:Description>

<rdf:Description rdf:about="http://www.w3.org/2004/02/skos/core#topConceptOf">

<skos:definition xml:lang="en">Definition: Super property of ISO isPartOf of a ThesaurusConcept having its attribute topConcept = true.

Captures ISO TopLevelRelationship</skos:definition>

</rdf:Description>

<rdf:Description rdf:about="http://www.w3.org/2004/02/skos/core#hasTopConcept">

<skos:definition xml:lang="en">Definition: Captures ISO TopLevelRelationship</skos:definition>

</rdf:Description>

<rdf:Description rdf:about="http://www.w3.org/2004/02/skos/core#memberList">

<rdfs:comment xml:lang="en">ISO

- hasMemberArray<ordered=true>

- hasMemberConcept<ordered=true></rdfs:comment>

www.episecc.eu

</rdf:Description>

<rdf:Description rdf:about="http://www.w3.org/2004/02/skos/core#member">

<rdfs:comment xml:lang="en">ISO

- hasMemberArray

- hasMemberConcept

- hasAsMember

Note: SKOS S39 (any concept in a List of a skos:memberList is also a value of skos:member).

By definition, used to represent members of a thesaurus Array or of a thesaurus Group.

An Array may have as members thesaurus Concepts or other thesaurus Arrays.

Thesaurus Group members are thesaurus Concepts.</rdfs:comment>

</rdf:Description>



<rdf:Description rdf:about="http://www.w3.org/2004/02/skos/core#Concept">

<rdfs:comment xml:lang="en">super class of ISO ThesaurusConcept

The mandatory attribute identifier may be mapped to the Dublin Core property dc:identifier.

Attributes or associations not detailed below typically are mapped to dc: (or dct:) properties:

- dct:created

- dct:modified</rdfs:comment>

</rdf:Description>



<rdf:Description rdf:about="http://www.w3.org/2004/02/skos/core#ConceptScheme">

<rdfs:comment xml:lang="en">super class of ISO Thesaurus

The mandatory attribute identifier may be mapped to the Dublin Core property dc:identifier. A typical representation of a thesaurus should document a (scoped) relationship between an identifier of this thesaurus and the URI of the RDF Concept Scheme URI.

The mandatory attribute lang can be mapped to either of the Dublin Core properties dc:language or dct:language. The value space is defined by RFC 4646. For multilingual thesaurus, one lang attribute is needed per supported language.

Typically these can be mapped to the corresponding Dublin Core dc: (or dct:) properties:

- dc:contributor

- dc:coverage

- dc:creator

- dct:created

- dct:modified

- dc:date

- skos:definition

- dc:format

- dc:publisher

- dc:relation, dct:relation or a specialization

- dc:rights

- dc:source

- dc:subject

- dc:title

- dc:type

The association "hasVersion" is discussed in the Version_History section of the mapping documentation (http://www.niso.org/schemas/iso25964/correspondencesSKOS/).</rdfs:comment>

</rdf:Description>

www.episecc.eu



<rdf:Description rdf:about="http://www.w3.org/2008/05/skos-xl#Label">

<rdfs:comment xml:lang="en">Super class of ISO ThesaurusTerm and of ISO NodeLabel.

A ThesaurusTerm has mandatory attributes lexicalValue and identifier. lexicalValue can be mapped to skos xl:literalForm. The value of identifier can be used as the URI of the skos xl:Label or as the object of a dc:identifier statement on that skos-xl:Label.

A NodeLabel has mandatory attributes lexicalValue.

The optional ISO25964 lang attribute of ThesaurusTerm and of NodeLabel must be mapped to RDF language tag for RDF plain literals.

Attributes or associations not detailed below typically are mapped to dc: (or dct:) properties:

- dct:created

- dct:modified

- dc:source</rdfs:comment>

</rdf:Description>

</rdf:RDF>

www.episecc.eu

II. An excerpt of the test database

OWL file below is an excerpt from the test database of the Semantic Repository written in RDF/XML

syntax and containing one Concept Scheme, seven Thesaurus Arrays, 17 Concepts and 24 Preferred

Terms.

<?xml version="1.0"?>

<!DOCTYPE rdf:RDF [

<!ENTITY terms "http://purl.org/dc/terms/" >

<!ENTITY owl "http://www.w3.org/2002/07/owl#" >

<!ENTITY xsd "http://www.w3.org/2001/XMLSchema#" >

<!ENTITY skos-xl "http://www.w3.org/2008/05/skos-xl#" >

<!ENTITY skos-thes "http://purl.org/iso25964/skos-thes#" >

<!ENTITY skos "http://www.w3.org/2004/02/skos/core#" >

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

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

]>

<rdf:RDF xmlns="http://www.episecc.eu/sem_rep#"

xml:base="http://www.episecc.eu/sem_rep"

xmlns:skos-thes="http://purl.org/iso25964/skos-thes#"

xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"

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-xl="http://www.w3.org/2008/05/skos-xl#"

xmlns:skos="http://www.w3.org/2004/02/skos/core#">

<owl:Ontology rdf:about="http://www.episecc.eu/sem_rep">

<owl:imports rdf:resource="http://purl.org/iso25964/skos-thes"/>

</owl:Ontology>





<owl:AnnotationProperty rdf:about="&terms;description"/>

www.episecc.eu



<owl:NamedIndividual rdf:about="http://www.episecc.eu/sem_rep#epi00001">

<rdf:type rdf:resource="&skos;ConceptScheme"/>

<rdfs:label xml:lang="en">EPISECC</rdfs:label>

<terms:description xml:lang="en">The EPISECC thesaurus contains concepts describing: a response to a critical event.</terms:description>

</owl:NamedIndividual>



<rdf:type rdf:resource="&skos;Concept"/>

<rdfs:label xml:lang="en">A response to a critical event</rdfs:label>

<terms:description xml:lang="en">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.</terms:description>

<skos:inScheme rdf:resource="http://www.episecc.eu/sem_rep#epi00001"/>

<skos:topConceptOf rdf:resource="http://www.episecc.eu/sem_rep#epi00001"/>

<skos-xl:prefLabel rdf:resource="http://www.episecc.eu/sem_rep#epi00003"/>

<skos-thes:subordinateArray rdf:resource="http://www.episecc.eu/sem_rep#epi00004"/>



<skos:narrower rdf:resource="http://www.episecc.eu/sem_rep#epi00014"/>








<rdf:type rdf:resource="&skos-thes;PreferredTerm"/>

<rdfs:label xml:lang="en">A response to a critical event (label)</rdfs:label>

<skos-xl:literalForm xml:lang="en">A response to a critical event</skos-xl:literalForm>





<rdf:type rdf:resource="&skos-thes;ThesaurusArray"/>

<rdfs:label xml:lang="en">Capacity (facet)</rdfs:label>

<terms:description xml:lang="en">A combination of both tangible and intangible means available within an organisation that can be used in a response to a critical event. </terms:description>



<skos:member rdf:resource="http://www.episecc.eu/sem_rep#epi00010"/>


www.episecc.eu





<rdfs:label xml:lang="en">Capacity (facet) (label)</rdfs:label>

<skos-xl:literalForm xml:lang="en">Capacity</skos-xl:literalForm>






<rdfs:label xml:lang="en">Disaster (facet)</rdfs:label>

<terms:description xml:lang="en">“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).</terms:description>







<rdfs:label xml:lang="en">Disaster (facet) (label)</rdfs:label>

<skos-xl:literalForm xml:lang="en">Disaster</skos-xl:literalForm>






<rdfs:label xml:lang="en">Organisation (facet)</rdfs:label>

<terms:description xml:lang="en">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.</terms:description>









www.episecc.eu

<rdfs:label xml:lang="en">Organisation (facet) (label)</rdfs:label>

<skos-xl:literalForm xml:lang="en">Organisation</skos-xl:literalForm>






<rdfs:label xml:lang="en">Capability (facet)</rdfs:label>

<terms:description xml:lang="en">Ability to response to a disaster in relation to capacity.</terms:description>









<rdfs:label xml:lang="en">Capability (facet) (label)</rdfs:label>

<skos-xl:literalForm xml:lang="en">Capability</skos-xl:literalForm>






<rdfs:label xml:lang="en">Capacity type (facet)</rdfs:label>

<terms:description xml:lang="en">A category of a capacity having common characteristics related to mean’s characteristics.</terms:description>








<rdfs:label xml:lang="en">Capacity type (facet) (label)</rdfs:label>

<skos-xl:literalForm xml:lang="en">Capacity type</skos-xl:literalForm>






www.episecc.eu



<rdfs:label xml:lang="en">Capable</rdfs:label>

<terms:description xml:lang="en">Ability to response to a disaster in relation to capacity.</terms:description>







<rdfs:label xml:lang="en">Capable (label)</rdfs:label>

<skos-xl:literalForm xml:lang="en">Capable</skos-xl:literalForm>






<rdfs:label xml:lang="en">Incapable</rdfs:label>

<terms:description xml:lang="en">An organisation has not capability to respond to a disaster.</terms:description>







<rdfs:label xml:lang="en">Incapable (label)</rdfs:label>

<skos-xl:literalForm xml:lang="en">Incapable</skos-xl:literalForm>






<rdfs:label xml:lang="en">Partially capable</rdfs:label>

<terms:description>An organisation has partial capability to respond to a disaster.</terms:description>







www.episecc.eu



<rdfs:label xml:lang="en">Partially capable (label)</rdfs:label>

<skos-xl:literalForm xml:lang="en">Partially capable</skos-xl:literalForm>






<rdfs:label xml:lang="en">Competence</rdfs:label>

<terms:description xml:lang="en">The ability, in terms of having adequate skills and knowledge, to efficiently cope with a situation caused by a critical event.</terms:description>
















<rdfs:label xml:lang="en">Competence (label)</rdfs:label>

<skos-xl:literalForm xml:lang="en">Competence</skos-xl:literalForm>






<rdfs:label xml:lang="en">Resource</rdfs:label>

<terms:description xml:lang="en">Assets an organisation has available for the response to a critical event.</terms:description>










www.episecc.eu




<rdfs:label xml:lang="en">Resource (label)</rdfs:label>

<skos-xl:literalForm xml:lang="en">Resource</skos-xl:literalForm>






<rdfs:label xml:lang="en">Coordination</rdfs:label>

<terms:description xml:lang="en">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.</terms:description>







<rdfs:label xml:lang="en">Coordination (label)</rdfs:label>

<skos-xl:literalForm xml:lang="en">Coordination</skos-xl:literalForm>






<rdfs:label xml:lang="en">Emergency medical service</rdfs:label>

<terms:description xml:lang="en">An ability to treat and transport people that may be life threatening or injured during a response to a critical event.</terms:description>







<rdfs:label xml:lang="en">Emergency medical service (label)</rdfs:label>

<skos-xl:literalForm xml:lang="en">Emergency medical service</skos-xl:literalForm>





www.episecc.eu




<rdfs:label xml:lang="en">Evacuation</rdfs:label>

<terms:description xml:lang="en">An ability to immediately and urgently move people away from the threat or actual occurrence of a hazard.</terms:description>







<rdfs:label xml:lang="en">Evacuation (label)</rdfs:label>

<skos-xl:literalForm xml:lang="en">Evacuation</skos-xl:literalForm>






<rdfs:label xml:lang="en">Firefighting</rdfs:label>

<terms:description xml:lang="en">An ability to perform an action or process of extinguishing fires.</terms:description>







<rdfs:label xml:lang="en">Firefighting (label)</rdfs:label>

<skos-xl:literalForm xml:lang="en">Firefighting</skos-xl:literalForm>






<rdfs:label xml:lang="en">Humanitarian aid</rdfs:label>

<terms:description xml:lang="en">An ability to provide material or logistical assistance for humanitarian purposes.</terms:description>





www.episecc.eu





<rdfs:label xml:lang="en">Humanitarian aid (label)</rdfs:label>

<skos-xl:literalForm xml:lang="en">Humanitarian aid</skos-xl:literalForm>






<rdfs:label xml:lang="en">Protection of property</rdfs:label>

<terms:description xml:lang="en">An ability to assess the damage and protect structures and objects as an action of a response to a critical event.</terms:description>







<rdfs:label xml:lang="en">Protection of property (label)</rdfs:label>

<skos-xl:literalForm xml:lang="en">Protection of property</skos-xl:literalForm>






<rdfs:label xml:lang="en">Protection of cultural heritage</rdfs:label>

<terms:description xml:lang="en">An ability to assess the damage and protect cultural heritage as a action of a response to a critical event.</terms:description>







<rdfs:label xml:lang="en">Protection of cultural heritage (label)</rdfs:label>

<skos-xl:literalForm xml:lang="en">Protection of cultural heritage</skos-xl:literalForm>




www.episecc.eu





<rdfs:label xml:lang="en">Protection of critical infrastructure</rdfs:label>

<terms:description xml:lang="en">An ability to assess the damage and protect critical infrastructure as an action of a response to a critical event.</terms:description>







<rdfs:label xml:lang="en">Protection of critical infrastructure (label)</rdfs:label>

<skos-xl:literalForm xml:lang="en">Protection of critical infrastructure</skos-xl:literalForm>






<rdfs:label xml:lang="en">Search and rescue</rdfs:label>

<terms:description xml:lang="en">An ability to perform search for and aid to people who are in distress or imminent.</terms:description>







<rdfs:label xml:lang="en">Search and rescue (label)</rdfs:label>

<skos-xl:literalForm xml:lang="en">Search and rescue</skos-xl:literalForm>






<rdfs:label xml:lang="en">Resource status (facet)</rdfs:label>

<terms:description xml:lang="en">The status of the resource regarding its availability for deployment.</terms:description>



www.episecc.eu









<rdfs:label xml:lang="en">Resource status (facet) (label)</rdfs:label>

<skos-xl:literalForm xml:lang="en">Resource status</skos-xl:literalForm>






<rdfs:label xml:lang="en">Resource type (facet)</rdfs:label>

<terms:description xml:lang="en">A category of a resource having common characteristics.</terms:description>







<rdfs:label xml:lang="en">Resource type (facet) (label)</rdfs:label>

<skos-xl:literalForm xml:lang="en">Resource type</skos-xl:literalForm>






<rdfs:label xml:lang="en">Available</rdfs:label>

<terms:description xml:lang="en">A resource is available for deployment.</terms:description>






<rdfs:label xml:lang="en">Available (label)</rdfs:label>

<skos-xl:literalForm xml:lang="en">Available</skos-xl:literalForm>


www.episecc.eu






<rdfs:label xml:lang="en">Unavailable</rdfs:label>

<terms:description xml:lang="en">A resource is not available for deployment.</terms:description>







<rdfs:label xml:lang="en">Unavailable (label)</rdfs:label>

<skos-xl:literalForm xml:lang="en">Unavailable</skos-xl:literalForm>



</rdf:RDF>

d4.3. data model - episecc · developed. using unified modelling language (uml) use case diagram,...

Documents