Conference PaperPDF Available

Abstract and Figures

In crisis management, it is crucial to have up-to-date data available to assess an ongoing situation correctly. This information originates from different sources, such as human observations, various sensors or simulation algorithms with heterogeneous geographic scope. The aggregation of such data is conducted by decision support systems to disburden the end-users from automatable tasks. By using semantic technologies for the integration, these systems can benefit from the expressional power of semantic queries. Therefore, all data that is available in the system should also be accessible for these queries. In the following, we present an approach how sensor data can be accessed through semantic queries and how geospatial knowledge can be integrated in a Decision Support System.
Content may be subject to copyright.
Semantic Queries Supporting Crisis Management Systems
Manfred Schenk, Tobias Hellmund,
Philipp Hertweck and J¨
urgen Moßgraber
Fraunhofer Institute of Optronics, System Technologies and Image Exploitation IOSB
Karlsruhe, Germany
Email: {manfred.schenk, tobias.hellmund,
philipp.hertweck, juergen.mossgraber}@iosb.fraunhofer.de
Abstract—In crisis management, it is crucial to have up-to-date
data available to assess an ongoing situation correctly. This
information originates from different sources, such as human
observations, various sensors or simulation algorithms with
heterogeneous geographic scope. The aggregation of such data is
conducted by decision support systems to disburden the end-users
from automatable tasks. By using semantic technologies for the
integration, these systems can benefit from the expressional power
of semantic queries. Therefore, all data that is available in the
system should also be accessible for these queries. In the following,
we present an approach how sensor data can be accessed through
semantic queries and how geospatial knowledge can be integrated
in a Decision Support System.
Keywordsdecision support; semantic access to sensor observa-
tions; GeoSPARQL; geospatial semantic queries.
I. INTRODUCTION
Being a specialized sub-category of a Decision Support
System (DSS), crisis management systems are designed to
support authorities in handling a crisis by providing collected
and analyzed information as well as simulation results. While
in the past the lack of information was one of the biggest
challenges, the situation has changed now. Since the advent
of the Internet of Things (IoT) placing great numbers of
connected sensors the amount of available data has increased
[1]. This results in new challenges: The decision makers have
to be protected from information overflow [2] and the input
from different heterogeneous sources has to be integrated and
automatically analyzed.
Why is geospatial knowledge important in crisis manage-
ment? A crisis situation usually will be limited to a certain area
in most cases. When a high level of water in a river causes
flooding of the land along the riverbanks, this flooding will be
limited to a certain area surrounding the river. The knowledge
about this area allows reducing the amount of data which has to
be considered in the crisis management workflows. Thus, the
location of a sensor or its observation can be used for filtering
data that is of no value for the current crisis; the location of
a human observer can be used to estimate the validity of a
given statement; the geometry of an urban district can be used
to determine if the district is affected by some event.
Our approach is to use semantic technologies to integrate
information from different sources and then apply reasoning
to draw conclusions from the gathered information focusing
on the semantics of geospatial data. While Kontopoulos et
al. presented the overall approach in [3] and [4], this paper
concentrates on two parts of the approach: firstly, accessing
of time series data, e.g. sensor observations and, secondly,
exploiting geospatial knowledge.
The paper is structured as follows: Related Work introduces
preliminaries and gives a brief overview of recent work. In
Section 3 - Using geospatial knowledge, the motivation for
the semantic integration of geospatial information in a crisis
situation given. It is described how geospatial semantics can
be integrated in a machine-understandable manner. Further,
geoSPARQL [5] with possible applications is introduced.
Section 4 - Semantic Access to Sensor Data - gives different
approaches how sensors and their geospatial semantics can be
integrated into a DSS. We present our approach for the integra-
tion and retrieval of such data with the standard SensorThings
API [6] and ONT-D2RQ [7]. Section 5 - Use-Case Applica-
tion describes the application of the developed functionalities
within the project beAWARE [8]. We give an exemplaric query
and analyze its architecture. Section 6 evaluates the approach
on a qualitative base. Section 7 concludes our findings and
gives an outlook on future tasks.
II. RE LATE D WORK
Parts of the work presented here are based on the
Open Geospatial Consortium (OGC) standard GeoSPARQL
[5]. Battle and Kolas [9] provide a good introduction
into GeoSPARQL. Zhang et al. [10] have already consid-
ered GeoSPARQL useful in the area of crisis management.
While they concentrated on performance improvements of
the GeoSPARQL implementations, our focus is how to bring
all parts together. Nishanbaev et al. provided a survey of
geospatial semantic web for cultural heritage [11]. While the
survey focused on cultural heritage, major parts of it are also
valid for the topic of crisis management.
The integration of databases into semantic systems has
been adressed by Bizer and Seaborne [12] in their descrip-
tion of the D2RQ project. Hert et al. [13] also provided a
comparison of several relational database to RDF mapping
languages. Santipantakis et al. [14] also described the use
of database to ontology mapping systems for the maritime
domain. A discussion on the integration of sensors into a crisis
management system can be found in [15]. The beAWARE
ontology, which was used for the evaluation of our approach
has been presented in [3]. The ontology integrates aspects
of the domain sensors and observations, as well as metadata
for geospatial information. Hence, we continue using this
ontology.
III. USI NG G EO SPATIAL KNOW LE DG E
As already stated in the introduction, locations of events,
places, buildings, creatures, etc., play an important role in crisis
management. Locations can be expressed in different ways:
Technical documentation will most likely provide coordinates
of objects like sensors or buildings. In contrast, people tend
to use symbolic locations, e.g. ”The fire at the cathedral in
Paris” or ”the traffic accident at the crossing of St. James Street
and Independance Avenue”. Sometimes, these symbolic loca-
tions are also called well-known places. Therefore, all those
different types of location descriptions should be supported
and there should be some automatic mapping between them.
The resolving of symbolic locations is done with the help of
gazetteers. A gazetteer is a geographical dictionary providing
several information about the recorded well-known places,
e.g. the location or geometry, the population, etc. A popular
example available on the internet is GeoNames [16]. Some
of those gazetteers can even be accessed via SPARQL and
therefore can be integrated into a semantic crisis management
system.
In some use-cases, the amount of data can be further
restricted to increase the usability of the system. If some events
are visualized on a map, only the events that are located
inside the visual part of the map are of interest. Therefore,
the semantic query used for populating the map should utilize
the information about the map’s viewport. In this case, we
have two geospatial restrictions for the data: process only data
which is located inside the area which is affected by the crisis
situation, process only data which is located inside the area
visualized by the current viewport.
There are two preconditions for the use of such geospatial
knowledge as part of semantic queries: First, the collected
data has to be in relation with a location or geometry. This
can either be explicit, e.g. the documented location of a
sensor, or the geospatial information can be inferred, e.g.
some textual statement mentions a well-known place. The
second requirement is geospatial support of the semantic query
engine. The GeoSPARQL extension from the OGC addresses
this requirement. It provides SPARQL extension functions for
geographic information. According to the standard document
[5], GeoSPARQL provides the following features:
An RDF/OWL vocabulary for representing spatial
information consistent with the Simple Features model
[17]
A set of SPARQL extension functions for spatial
computations
A set of RIF (Rule Interchange Format [18]) rules for
query transformation (not in the scope of this paper)
The vocabulary defines top-level spatial vocabulary compo-
nents, as well as geometry vocabulary and topological relation
vocabulary. Since the definition of relations can follow differ-
ent approaches, GeoSPARQL supports three of these relation
families: The Simple Features family follows the OpenGIS
Simple Features specification [17], the Egenhofer family fol-
lows the formal definition of binary topological relationships
by Egenhofer [19] and the RCC8 family follows the Region
Connection Calculus by Randell et al. [20]. The SPARQL
extension functions can be divided into topological and non-
topological query functions. The topological functions contain
relations like equals,intersects,touches,contains,overlaps,
etc. and are defined for each of the different relation fami-
lies mentioned above. The non-topological functions contain
relations like distance,buffer,convexHull, etc.
Geometries can have different numbers of dimensions:
points (0-dimensional), lines (1-dimensional) and areas (2-
dimensional). The function equals can be applied to all geome-
try types and expresses that two instances of SpatialObject are
topologically equal, i.e. their interiors intersect and no part
of the interior or boundary of one geometry intersects the
exterior of the other. The function intersects can be also be
applied to all geometries and states that both geometries have
at least one point in common. The function touches can be
applied to all geometries with a dimension greater than zero
and expresses that both geometries have at least one boundary
point in common, but no interior points. The function overlaps
can be applied only to geometries with the same dimension.
It states that they have some but not all points in common
and the intersection of their interiors has the same dimension
as the geometries themselves. The function distance returns
the shortest distance in units between any two points in the
two geometries as calculated in the spatial reference system
of the first geometry. The function buffer returns a geometric
object that represents all points whose distances from the given
geometry are less than or equal to the given radius value
measured in the given units. The calculations are made within
the spatial reference system of the given geometry. Finally, the
function convexHull returns a geometric object that represents
all points in the convex hull of the given geometry.
The following enumeration lists examples of competency
questions from a crisis management system, which could
benefit from the integration of geospatial knowledge:
1) Which is the area with most people involved in an
incident?
2) Which is the area with the highest density of inci-
dents?
3) Will the playground be affected by the estimated
flood zone?
4) Is there enough shelter capacity for all people affected
by a specific incident type within a certain radius?
5) Where are the nearest sensors for a specific incident?
How can GeoSPARQL be used for answering those questions?
In the following examples, the functions from the Simple
Features relation family are used. The snippets are simplified
to show only the GeoSPARQL part of the whole query to keep
it short. For the first question, the locations of all incidents
have to be collected and then the number of persons involved
has to be aggregated for the different areas. In this case, the
contains respectively the sfContains function determines which
locations belong to which area as shown in the following
SPARQL snippet.
SELECT ?area ?incidentLocation
WHERE {
?area age o : w k t L i t e r a l ;
geo : sf C on t ai ns ? l o c L i t e r a l .
? i n c i d e n t L o c a t i o n geo : asWKT ? l o c L i t e r a l .
}
The second question is similar to the first one. If the
geometries of the playground and the estimated flood zone are
known, the intersects or overlaps functions will help answering
question three.
SELECT ?playground ?estFloodZone
WHERE {
? p l a yG r ou n d ge o : ha s G eo m et r y ? pla yG eo m .
? es t F l o o d Z o n e g e o : ha s G e om e t r y
?estFloodGeom .
? p lay Ge om g eo : asWKT ? p la y Wk t .
? e s t F l oo d G e o m ge o : asWKT ? e s t F l o o d W k t .
FILTER ( g e of : o v e r l a p s ( ? p lay Wk t ,
? es t F l o o d W k t )
}
Question four is more complex. At first, the affected area
has to be determined. With the help of the buffer function
the area for potential shelters is calculated. After that, the
matching shelters can be associated with those areas by using
the contains function and their capacity can be summed up per
area.
SELECT ? a f f e ct e d Zo n e ? i n c i d e n t L o c a t i o n
WHERE {
? i n c i d e n t L o c a t i o n geo : asWKT ? w k t I n c i d e nt .
BIND ( g e o f : b u f f e r ( ? w k t I n c i d e n t ,
uom : m e t r e ) AS ? a f f e c t e d Z o n e )
}
SELECT ? a f f e c t e d Z o n e ? s h e l t e r L o c a t i o n
WHERE {
? s h e l t e r L o c a t i o n geo : asWKT ? w k t S h el t e r .
? a f f e c t e d Z o n e ge o : s f C o n t a i n s ? w k t S h e l t e r .
}
The distance function will help answering the last question
if the location of the sensors and the incident location is
known.
SELECT ? s e n s o r Lo c a t io n ? i n c i d e n t L o c a t i o n
?distance
WHERE {
? s e n s o r L o c a t i o n ge o : asWKT ? w k t S en s o r .
? i n c i d e n t L o c a t i o n geo : asWKT ? w k t I n c i d e nt .
BIND ( g eo f : d i s t a n c e ( ? w kt Sen so r ,
? w k t I n c i d e n t , uom : m e t re ) a s ? d i s t a n c e )
}
ORDER BY DESC ( ? d i s t a n c e )
By using the functions mentioned above together with the
standard SPARQL features, queries that are more complex
can be built for the given questions. If some locations are
provided as well-known places, they will have to be mapped to
coordinates by some gazetteer services before they can be used
together with the GeoSPARQL functions. If those gazetteers
provide a SPARQL interface, the mapping can be done as part
of a federated query, meaning that some parts of a query are
sent to remote SPARQL endpoints and will be executed there.
IV. SEM AN TI C ACC ES S TO SE NS OR DATA
Changes in the environment can be observed by sensors
through a large number of parameters. Since these sensors
are usually connected to the internet, a large amount of
information is generated, which can be used as possible input
for decision support systems. Since we focus on the semantics
of the available data, the information should be semantically
integrated to make it accessible through semantic queries.
This integration could be done in several ways (in the
following sections, the term sensor management system is used
with the following meaning: A system that manages sensor
measurements and provides standardized access to the data
measured by them.):
Sensors store their data directly into an ontology or
use some generic adapter for this task
An existing sensor management system is enhanced
by a SPARQL interface
The SPARQL queries are mapped to some query
interface of an existing sensor management system
The database of an existing sensor management sys-
tem is accessed via some adaption layer which pro-
vides a SPARQL interface
The first option is enhancing each sensor in a way it stores
its data as described by the used ontology. However, since
this approach would require changes to each sensor it would
counteract the idea to use existing sensors as input. Even
if there were some generic adapters available for this task,
another problem would still exist: While some raw observation
data might not be suitable for the user of a Decision Support
System, the results of some simulations or forecasts based on
these observations are of greater value. Adding such simulation
and processing functionality to these adapters also would make
them less generic and increase their complexity. Furthermore,
it could lead to massive concurrent write access to the ontol-
ogy, causing a permanent index rebuild according to Pan et. al
[21]. Therefore, this approach was not continued any further.
Another solution would be to integrate a SPARQL inter-
face into an existing sensor management system. This would
leave the task of collecting and storing the sensor data to
an existing software, which follows a popular standard and
therefore enables the use of a great number of already existing
sensors. The OGC SensorThings API [6] is such a standard
from the OGC, which provides a unified way to interconnect
Internet of Things devices, data, and applications over the web.
From the list of available implementations, the FROST-Server
[22] is used for the current research. It uses a PostgreSQL
relational database for the actual storage of the sensor data.
Since the FROST-Server is an open-source implementation,
integrating an additional SPARQL interface should be feasible.
The second part of the SensorThings API standard already
specifies how simulation and processing tasks can interact with
an implementation of the standard.
Some small changes to this second solution leads to the
third possibility: While the SPARQL interface of the previous
solution would have direct access to the internals of the
FROST-Server, in this approach it would be decoupled by
only using the existing query interface of the server. This
approach would not require changes to the implementation of
the FROST-Server, but the mapping between SPARQL and the
query interface would have to be implemented from scratch.
A fourth approach would be to access the underlying
database of the FROST-Server via some adaption layer instead
of enhancing the server itself. This would keep the server
Figure 1. SensorThings Datamodel (from the OGC SensorThings API standard)
implementation simple by keeping out functionality, which
is only used in some use cases. By using this approach, the
original problem Semantic access to sensor data is transformed
into the problem Semantic access to relational databases. For
the transformed problem, there are already multiple solutions
available: one of them, the D2RQ project [23] provides a
generic implementation for accessing relational databases as
virtual, read-only RDF graphs [12] [13]. The original project
has been extended in the meantime by the community as part
of the project ONT-D2RQ [7] to support OWL in addition to
RDF.
Since the fourth approach promises to reach the goal with
only a minimum of software development, it has been chosen
and the idea of integrating a SPARQL interface directly into
a sensor management system has been postponed.
The D2RQ-Server requires a mapping between the
database tables and an ontology. As a first attempt, a sim-
ple ontology is created, representing the data model of the
SensorThings API (see Figure 1). Parts of this ontology are
integrated into the beAWARE Ontology, presented in [3]. The
entities of this model are directly mapped to tables in the im-
plementation of the FROST-Server. Therefore, table mapping
means entity-mapping in our case. Each of the main entities is
represented by an OWL class. The relations between entities
are modeled as ObjectProperties. Finally, DatatypeProperties
are used for the attributes of an entity. Since the relations of
the SensorThings data model are not directed, there has to be
an inverse ObjectProperty defined for each ObjectProperty. The
actual mapping for ONT-D2RQ is defined in a configuration
file.
Using the new modular Semantic Sensor Network Ontol-
ogy (SSN, [24] would have been an alternative to the creation
of an own simple ontology, but the complexity of the mapping
would have been higher and some aspects of the SensorThings
API which are not covered by the SSN would have required
some additional extensions as well.
V. US E- CA SE AP PL IC ATIO N
The integration of geospatial knowledge and sensor ob-
servation data with the help of ontologies (as introduced in
Section 3 and 4) has been evaluated as part of the research
project beAWARE: “Enhancing decision support and manage-
ment services in extreme weather climate events” [8]. The
goal is to develop an integrated solution to manage climate-
related crises in all phases, starting with early warning before,
managing during and recovery after the event.
A great number of sensors has been connected to the
system for the surveillance of water levels, temperatures,
1PREFIX webgenesis : <h t t p : / / a r q e x t . w e b g e n e s i s . de / >
2PREFIX beaw : <h t t p : / / be awarep r o j e c t . e u / beAWARE/ #>
3PREFIX s t h : <h t t p : / / www. i o sb . f r a u n h o f e r . d e / f r o s t #>
4PREFIX g e o f : <h t t p : / / www . o p e n g i s . n e t / d ef / f u n c t i o n / g e o s p a r q l />
5PREFIX uom : <h t t p : / / www. o p e n g i s . n e t / d e f / uom /OGC / 1 . 0 / >
6
7SELECT ? l o c a t i o n ? j s on L oc ? wk t Lo c In c ? w kt Lo c ? d i s t a n c e
8WHERE {
9{SELECT ? l o c a t i o n ? js o n L oc ? wk t L o c In c WHERE {
10 SERVICE <h t t p : / / l o c a l h o s t : 20 20 / s p a r q l />{
11 ? l o c a t i o n as t h : L o c a t i o n ;
12 s t h : LOCATIONS LOCATION ? js o n L o c .
13 }
14 ? w k t L o c I nc w e b g en e s i s : c on ver tG eoJ SO N2 WKT ? j s o n L o c .
15 }}
16 {{
17 ? i n c i d e n t R e p o r t L o c a t i o n bea w : l a t i t u d e : l a t ;
18 be aw : l o n g i t u d e : l on .
19 ? w kt L oc w e b g e n e s i s : c on v er tL a tL o n2 W KT ( : l a t : l o n ) .
20 }}
21 BIND ( g e of : d i s t a n c e ( ? wk tLoc , ? wktLocIn c , uom : m e t re ) AS ? d i s t a n c e ) .
22 }
Figure 2. A geoSPARQL-enhanced SPARQL query retrieving geospatial information
humidity, etc. The sensor observation data is stored inside
the FROST-Server via the SensorThingsAPI interface. For the
SPARQL access to these observations, the D2RServer from
ONT-D2RQ has been chosen. It also supports OWL, whereas
the original D2RQ implementation only supported RDF.
Since the different sources for crisis management system
do not necessarily use the same representation for geospa-
tial location data, we have implemented additional custom
SPARQL extensions for converting between those repre-
sentations, e.g. the webgenesis:convertGeoJSON2WKT prop-
erty function converts the GeoJSON geometries delivered
by the FROST-Server to a WKT representation required by
GeoSPARQL.
Figure 2 shows a SPARQL query combining GeoSPARQL
with information from within the FROST-Server. This example
is constructed from several subqueries and uses the federated
queries feature of SPARQL:
1) The subquery shown in lines 10 to 13 is sent to
the SPARQL-endpoint of the ONT-D2RQ Server
and processed there. This endpoint will then re-
turn all locations which have the DatatypeProperty
sth:LOCATIONS LOCATION set.
2) In the next step, those results are converted from Geo-
JSON to WKTLiterals by the use of custom property
functions. This is the purpose of the subquery shown
in lines 9 to 15.
3) For the incident locations, there is also a previous
conversion step to have the data available as WK-
TLiterals. This conversation step is shown in lines
16 to 20.
4) Finally, the converted locations are used as part
of a GeoSPARQL query to determine the distance
between those observation locations and incident lo-
cations from the beAWARE ontology.
Similar SPARQL queries have been developed for the com-
petency questions of the beAWARE decision support system.
The query results are presented to the decision maker by
means of different visualizations ranging from a simple list
to geographical maps. The applicability of the approach used
for the beAWARE decision support system was validated by
two large-scale trials up to now an in one up-coming third trial.
The evaluation report [25] of the first trial is publicly available
on the project website [8].
VI. EVALUATIO N
The feasibility of our approach could be shown, but also
some problems were identified which have to be addressed
before the implementation can be used in production: The
performance of the mapping between the relational database
and the semantic representation is not fast enough. This causes
network timeouts of the SPARQL requests and degrades the
usability of the system, if the user has to wait several minutes
for the results of queries which were expected to be simple
queries. Since the author of the SPARQL queries does not
know how these queries will be mapped to SQL queries by
the D2RQ implementation, the mapping may produce non-
optimal SQL statements. The original D2RQ implementation
already provided some optimizations to address this deficiency
when handling large datasets, but it seems that not all of them
are still present in the ONT-D2RQ implementation. Since both
implementations provide different feature sets and the common
features of both are not sufficient for our system, a direct
comparison with a defined dataset was not possible.
The use of federated queries has been identified as another
bottleneck: Since the variable bindings of such a query have to
be transferred to the remote endpoint via the network and after
the execution, the results will traverse the network again, some
delay caused by the network has to be considered. In particular,
the missing support of LIMIT and OFFSET restrictions for the
federated queries makes the situation even more badly. Even
in the cases where only a few results are needed from the
remote SPARQL endpoint, that endpoint has to process the
whole dataset and return a possibly large number of results,
despite the fact that most of these results will then be thrown
away by some LIMIT or OFFSET clause of the surrounding
query.
In November 2019, the last beAWARE pilot will be con-
ducted. Here, a quantitative benchmark will be performed.
With these results, measures to improve the performance will
be developed.
VII. CONCLUSION
In this paper, we presented the usage of GeoSPARQL
for the integration of geospatial knowledge into a Decision
Support System for crisis management based on semantic tech-
nologies. Competency questions that are of interest for such
DSS were introduced, as well as their formal representations as
geoSPARQL enhanced SPARQL queries. To access sensor data
on a semantic base, the data must be semantically integrated.
We introduced four possible ways how this could be achieved
and how sensor observation data could be accessed from within
such a system. In the Use-Case Application section, we dis-
cussed how these parts were combined within the EU-funded
project beAWARE. As further task, performance optimization
has been identified. In November, the last beAWARE pilot
will take place in Valencia, where quantitative measures will
be implemented to evaluate the systems performance. Finally,
the evaluation of the approach within the project has been
presented.
ACKNOWLEDGMENT
The research leading to these results has received funding
from the European Union’s Horizon 2020 research and innova-
tion programme under Grant Agreement No 700395 and Grant
Agreement No 700475.
REFERENCES
[1] T. Usl¨
ander et al., “The trend towards the internet of things: what does
it help in disaster and risk management?” Planet@ Risk, vol. 3, no. 1,
2015, pp. 140–145.
[2] M. van den Homberg, R. Monn´
e, and M. R. Spruit, “Bridging the infor-
mation gap: mapping data sets on information needs in the preparedness
and response phase,” Technologies for Development, 2018, p. 213.
[3] E. Kontopoulos, P. Mitzias, J. Moßgraber, P. Hertweck, H. van der
Schaaf, D. Hilbring, F. Lombardo, D. Norbiato, M. Ferri, A. Karakostas
et al., “Ontology-based representation of crisis management procedures
for climate events.” in ISCRAM, 2018, pp. 1064–1073.
[4] E. Kontopoulos, P. Mitzias, S. Dasiopoulou, M. J., S. Mille, P. Her-
tweck, T. Hellmund, A. Karakostas, S. Vrochidis, L. Wanner, and
I. Kompatsiaris, “Applying semantic web technologies for decision
support in climate-related crisis management,” in Proceedings Citizen
Observatories for natural hazards and Water management. 2nd Int. Conf.
on Citizen Observatories for natural hazards and Water Management
(COWM 2018). COWM, 2018.
[5] M. Perry and J. Herring, “Ogc geosparql-a geographic query language
for rdf data,” OGC implementation standard., 2012, last access
date: 2019-09-05. [Online]. Available: https://www.opengeospatial.org/
standards/geosparql
[6] S. Liang, C.-Y. Huang, T. Khalafbeigi et al., “Ogc sensorthings api-
part 1: Sensing,” OGC R Implementation Standard. Available online:
http://docs. opengeospatial. org/is/15-078r6/15-078r6. html (accessed on
14 April 2018), 2016.
[7] A database to owl mapper. Last access date: 2019-09-05. [Online].
Available: https://github.com/avicomp/ont-d2rq
[8] beware project homepage. Last access date: 2019-09-05. [Online].
Available: https://beaware-project.eu/
[9] R. Battle and D. Kolas, “Geosparql: enabling a geospatial semantic
web,” Semantic Web Journal, vol. 3, no. 4, 2011, pp. 355–370.
[10] C. Zhang, T. Zhao, L. Anselin, W. Li, and K. Chen, “A map-reduce
based parallel approach for improving query performance in a geospatial
semantic web for disaster response,” Earth Science Informatics, vol. 8,
no. 3, 2015, pp. 499–509.
[11] I. Nishanbaev, E. Champion, and D. A. McMeekin, “A survey of
geospatial semantic web for cultural heritage,” Heritage, vol. 2, no. 2,
2019, pp. 1471–1498.
[12] C. Bizer and A. Seaborne, “D2rq-treating non-rdf databases as virtual
rdf graphs,” in Proceedings of the 3rd international semantic web
conference (ISWC2004), vol. 2004. Proceedings of ISWC2004, 2004.
[13] M. Hert, G. Reif, and H. C. Gall, “A comparison of rdb-to-rdf mapping
languages,” in Proceedings of the 7th International Conference on
Semantic Systems. ACM, 2011, pp. 25–32.
[14] G. Santipantakis, K. I. Kotis, and G. A. Vouros, “Ontology-based
data integration for event recognition in the maritime domain,” in
Proceedings of the 5th International Conference on Web Intelligence,
Mining and Semantics. ACM, 2015, p. 6.
[15] J. Moßgraber, D. Hilbring, H. van der Schaaf, P. Hertweck, E. Kon-
topoulos, P. Mitzias, I. Kompatsiaris, S. Vrochidis, and A. Karakostas,
“The sensor to decision chain in crisis management.” in ISCRAM, 2018,
pp. 754–763.
[16] Geonames gazetteer. Last access date: 2019-09-05. [Online]. Available:
https://www.geonames.org
[17] Opengis simple features specification for sql. Open GIS Consortium
and others. Last access date: 2019-09-05. [Online]. Available:
http://www.opengeospatial.org/standards/sfs (1999)
[18] M. Kifer and H. Boley, “Rif overview,” W3C working draft,
W3C, 2013, last access date: 2019-09-05. [Online]. Available:
http://www.w3.org/TR/rif-overview
[19] M. J. Egenhofer, “A formal definition of binary topological relation-
ships,” in International conference on foundations of data organization
and algorithms. Springer, 1989, pp. 457–472.
[20] D. A. Randell, Z. Cui, and A. G. Cohn, “A spatial logic based on regions
and connection.” KR, vol. 92, 1992, pp. 165–176.
[21] Z. Pan, T. Zhu, H. Liu, and H. Ning, “A survey of rdf management
technologies and benchmark datasets,” Journal of Ambient Intelligence
and Humanized Computing, vol. 9, no. 5, 2018, pp. 1693–1704.
[22] Fraunhofer open source sensorthings api server. Last access date:
2019-09-05. [Online]. Available: https://github.com/FraunhoferIOSB/
FROST-Server
[23] Accessing relational databases as virtual rdf graphs. Last access date:
2019-09-05. [Online]. Available: https://github.com/d2rq/d2rq
[24] Semantic sensor network ontology. W3C. Last access date: 2019-09-05.
[Online]. Available: https://www.w3.org/TR/vocab-ssn/ (2017)
[25] F. Lombardo, D. Norbiato, M. Ferri, I. Vourvachis, M. Meliadis,
A. Karakostas, I. Koulalis, T. Hellmund, and I. Koren, “D2.4
evaluation report of the 1st prototype,” in beAWARE H2020
project deliverable, last access date: 2019-09-05. [Online].
Available: https://beaware-project.eu/wp- content/uploads/2019/01/D2.
4-beAWARE Evaluation- report-of- P1 v0.5.pdf
... Integration of the sensor metadata (R2) and therefore adding semantic information is foreseen. Going a step further, it is even possible to access the sensor data using semantic queries [38]. ...
Article
Full-text available
Industrial Internet of Things (IIoT) applications are being used more and more frequently. Data collected by various sensors can be used to provide innovative digital services supporting increasing efficiency or cost reduction. The implementation of such applications requires the integration and analysis of heterogeneous data coming from a broad variety of sensors. To support these steps, this paper introduces OPAL, a software toolbox consolidating several software components for the semantically annotated integration and analysis of IoT-data. Data storage is realized in a standardized and INSPIRE-compliant way utilizing the SensorThings API. Supporting a broad variety of use cases, OPAL provides several import adapters to access data sources with various protocols (e.g., the OPC UA protocol, which is often used in industrial environments). In addition, a unified management and execution environment, called PERMA, is introduced to allow the programming language independent integration of algorithms.
Article
Full-text available
The amount of digital cultural heritage data produced by cultural heritage institutions is growing rapidly. Digital cultural heritage repositories have therefore become an efficient and effective way to disseminate and exploit digital cultural heritage data. However, many digital cultural heritage repositories worldwide share technical challenges such as data integration and interoperability among national and regional digital cultural heritage repositories. The result is dispersed and poorly-linked cultured heritage data, backed by non-standardized search interfaces, which thwart users’ attempts to contextualize information from distributed repositories. A recently introduced geospatial semantic web is being adopted by a great many new and existing digital cultural heritage repositories to overcome these challenges. However, no one has yet conducted a conceptual survey of the geospatial semantic web concepts for a cultural heritage audience. A conceptual survey of these concepts pertinent to the cultural heritage field is, therefore, needed. Such a survey equips cultural heritage professionals and practitioners with an overview of all the necessary tools, and free and open source semantic web and geospatial semantic web platforms that can be used to implement geospatial semantic web-based cultural heritage repositories. Hence, this article surveys the state-of-the-art geospatial semantic web concepts, which are pertinent to the cultural heritage field. It then proposes a framework to turn geospatial cultural heritage data into machine-readable and processable resource description framework (RDF) data to use in the geospatial semantic web, with a case study to demonstrate its applicability. Furthermore, it outlines key free and open source semantic web and geospatial semantic platforms for cultural heritage institutions. In addition, it examines leading cultural heritage projects employing the geospatial semantic web. Finally, the article discusses attributes of the geospatial semantic web that require more attention, that can result in generating new ideas and research questions for both the geospatial semantic web and cultural heritage fields.
Conference Paper
Full-text available
During climate-related crises vast volumes of heterogeneous multimodal information are generated. Meaningfully processing and communicating this information for efficient decision support is a key challenge. The paper describes applying Semantic Web technologies for decision support during such crises. We are proposing the application of these technologies in the whole “sensor to decision chain”. This approach is being tested within the beAWARE EU project, with contributions by domain experts.
Article
Full-text available
With the fast development of semantic web and some other areas, the amount of resource description framework (RDF) data has increased significantly. How to efficiently manage these masses of RDF data has become a challenging task, and has attracted many scholars to research. This paper introduces the state-of-the-art of the RDF storage and query technologies according to some classification criteria. In addition, several prevailing benchmark datasets are introduced and compared. Finally, research challenges and opportunities in future are discussed.
Conference Paper
Full-text available
In every disaster and crisis, incident time is the enemy, and getting accurate information about the scope, extent, and impact of the disaster is critical to creating and orchestrating an effective disaster response and recovery effort. Decision Support Systems (DSSs) for disaster and crisis situations need to solve the problem of facilitating the broad variety of sensors available today. This includes the research domain of the Internet of Things (IoT) and data coming from social media. All this data needs to be aggregated and fused, the semantics of the data needs to be understood and the results must be presented to the decision makers in an accessible way. Furthermore, the interaction and integration with existing risk and crisis management systems are necessary for a better analysis of the situation and faster reaction times. This paper provides an insight into the sensor to decision chain and proposes solutions and technologies for each step.
Conference Paper
Full-text available
One of the most critical challenges faced by authorities during the management of a climate-related crisis is the overwhelming flow of heterogeneous information coming from humans and deployed sensors (e.g. cameras, temperature measurements, etc.), which has to be processed in order to filter meaningful items and provide crisis decision support. Towards addressing this challenge, ontologies can provide a semantically unified representation of the domain, along with superior capabilities in querying and information retrieval. Nevertheless, the recently proposed ontologies only cover subsets of the relevant concepts. This paper proposes a more "all-around" lightweight ontology for climate crisis management, which greatly facilitates decision support and merges several pertinent aspects: representation of a crisis, climate parameters that may cause climate crises, sensor analysis, crisis incidents and related impacts, first responder unit allocations. The ontology could constitute the backbone of the decision support systems for crisis management. Keywords Crisis management, ontology, semantic integration, decision support, description logics. Kontopoulos et al. Ontology-based Representation of Crisis Management WiPe/CoRe Paper-Track Name
Article
Full-text available
Rapid retrieval of spatial information is critical to ensure that emergency supplies and resources can reach the impacted areas in the most efficient manner. However, it remains challenging to find out the needed spatial information efficiently because of the intensive geocomputation processes involved and the heterogeneity of spatial data. It is quite cost prohibitive to query the spatial information from geographical knowledge bases containing complex topological relationships. This research introduces a Map-Reduce based parallel approach for improving the query performance of a geospatial ontology for disaster response. The approach focuses on parallelizing the spatial join computations of GeoSPARQL queries. The proposed parallel approach makes full use of data/task parallelism for spatial queries. The results of some initial experiments show that the proposed approach can reduce individual spatial query execution time by taking advantage of parallel processes. The proposed approach, therefore, may afford a large number of concurrent spatial queries in disaster response applications.
Conference Paper
Full-text available
Recent environmental disasters at sea have highlighted the need for effi�cient maritime surveillance and incident management. Currently, maritime navigation technology automatically provides real time data from vessels, which together with historical data, can be processed in an integrated way to detect complex events and support decision making. Ontology-Based Data Access (OBDA) frameworks, can be employed to access data towards this e�ffort. However the heterogeneity of data in disparate sources make data integration a challenging task. In this paper we report on our eff�orts to implement a scalable system for integrating data from disparate data sources by means of existing OBDA frameworks and distributed E 􀀀 SHIQ knowledge bases, towards supporting complex event recognition. We present two versions of the implemented system, and the lessons learned from this e�ffort.
Article
Full-text available
According to the Gartners' hype cycle 2014, the emerging Internet of Things (IoT) has just reached the top of public awareness and expectations. However, looking beyond its use as a buzzword and the high expectations, there is a clear technological trend that will affect the amount and type of information that is available in Risk and Disaster Management. The seamless interconnection of devices to the Internet, being sensors of all types ranging from in-situ measurement devices, sensors on smart phones up to hyper-spectral cameras mounted on satellites, offers an enormous potential for the improvement in recognizing and assessing risks, for the targeted launch of preventive measures such as improved quality, preciseness and personalization of early warnings. The same is true for decision support in disaster management. However, to exploit this potential, there is an urgent need to improve interoperability. This paper argues for an open, standardized approach of sensor-based global information management based upon international standards. It provides an overview about the relevant initiatives (e.g. GEOSS, European Research Cluster on the Internet of Things IERC) and standardization bodies (e.g. ISO, OGC) and their architectural approaches for the IoT. Furthermore, it presents highlights and results of relevant projects, e.g. EO2HEAVEN in the domains of environment and health, TRIDEC for better decision support in tsunami early warning systems, and OpenIoT for an open source IoT software platform. The paper concludes with an assessment of the current user requirements and technological trends as well as a discussion of the next steps to be taken in order to exploit the IoT potential for the benefit of risk and disaster management improvement, however, also having in mind cyber security concerns.
Conference Paper
Full-text available
The exploration of spatial relationships is a multi-disciplinary effort involving researchers from linguistics, cognitive science, psychology, geography, cartography, semiology, computer science, surveying engineering, and mathematics. Terms like close and far or North and South are not as clearly understood as the standard relationships between integer numbers. The treatment of relationships among spatial objects is an essential task in geographic data processing and CAD/CAM. Spatial query languages, for example, must offer terms for spatial relationships; spatial database management systems need algorithms to determine relationships. Hence, a formal definition of spatial relationships is necessary to clarify the users' diverse understanding of spatial relationships and to actually deduce relationships among spatial objects. Based upon such formalisms, spatial reasoning and inference will be possible. The topological relationships are a specific subset of the large variety of spatial relationships. They are characterized by the property to be preserved under topological transformations, such as translation, rotation, and scaling. A model of topological relations is presented which is based upon fundamental concepts of algebraic topology in combination with set theory. Binary topological relationships may be defined in terms of the boundaries and interiors of the two objects to be compared. A formalism is developed which identifies 16 potential relationships. Prototypes are shown for the eight relationships that may exist between two objects of the same dimension embedded in the corresponding space.
Article
As the amount of Linked Open Data on the web increases, so does the amount of data with an inherent spatial context. Without spatial reasoning, however, the value of this spatial context is limited. Over the past decade there have been several vocabularies and query languages that attempt to exploit this knowledge and enable spatial reasoning. These attempts provide varying levels of support for fundamental geospatial concepts. In this paper, we look at the overall state of geospatial data in the Semantic Web, with a focus on the upcoming OGC standard GeoSPARQL. GeoSPARQL attempts to unify data access for the geospatial Semantic Web. We first describe the motivation for GeoSPARQL, then the current state of the art in industry and research, followed by an example use case, and the implementation of GeoSPARQL in the Parliament triple store.