The port of a city is a very dynamic environment that houses lots of companies. Ships come and go, and goods are always on the move. Information integration in geographic information systems is of great importance for tracking purposes, and for proactive and reactive incident handling by the port operators. Linked data and semantic web technologies can be of bene t for the integration of both streaming data such as location data about ships, trains and containers, with static data about companies, their activities and storage sites. With current RDF stream processors it is possible to execute SPARQL queries over RDF data streams taking into account static background data. However, none of them is capable of handling GeoSPARQL queries. GeoSPARQL is an extension to the SPARQL query language for processing geospatial data. To address this challenge we extended the RSP engine C-SPARQL with GeoSPARQL support, making it possible to query geospatial data streams.
Geospatial information is of great importance in a large number of application domains. Everything that happens, happens at a certain location. With the growth of the Internet of Things (IoT), it becomes more easy to track things and monitor actions happening somewhere at a certain place in the world. IoT sensors and devices constantly generate streams of data that describe their location, state, and the state of the context or environment they are active in.
The port of a city for example, is a very dynamic environment where lots of activities take place in which many actors are involved. It houses lots of companies, and goods are always on the move on the water or on land. Information integration in geographic information systems is of great importance for tracking purposes, and for proactive and reactive incident handling by the port operators. Linked data and semantic web technologies can be of bene t for the integration of streaming data such as location data about ships, trains, containers and the weather, with static data about infrastructure, companies, their activities, storage sites and others.
With the current RDF stream processors (RSPs) it is possible to execute
SPARQL queries over RDF data streams taking into account static semantic
background data [
The remainder of this paper is organized as follows. Section 2 represents the related work. It is followed by the section C-GeoSPARQL that explains the CSPARQL extension to support GeoSPARQL. Section 4 presents a use case and test environment regarding the port of the city of Ghent. 2
Semantic Web technologies like the data model RDF, the ontology language
OWL, and the RDF query language SPARQL allow to represent, integrate, query
and reason on heterogeneous data. However, these technologies were developed
for static or slow changing data sources. On the other end of the spectrum Data
Stream Management Systems (DSMS) and Complex Event Processing (CEP)
systems allow to query homogeneous streaming data structured according to a
xed data model. They are not able to deal with heterogeneous data sources
and lack support for the integration of domain knowledge. To bridge this gap,
stream reasoning has emerged as a challenging research area that focuses on the
adoption of Semantic Web technologies for streaming data [
GeoSPARQL is an Open Geospatial Consortium (OGC) standard published in 2012. It is a SPARQL extension that aims to address the issues of geospatial data representation and access. The GeoSPARQL speci cation provides a vocabulary, geometric class taxonomies and relations, for representing geospatial data in RDF. Moreover, it de nes extensions to the SPARQL query language to query and lter on the relationships between geospatial objects. Like for standard SPARQL there is no support for streaming data.
To the best of our knowledge Parliament [
The language stSPARQL [
Sextant [
The C-SPARQL architecture (Fig 1)1 is the result of an evolutionary approach in which existing solutions for streaming and semantic data are combined and treated as black-box subsystems. The two subsystems are a DSMS/CEP and a SPARQL engine. The rst copes with the windowing on the RDF streams and forwards the window content to the SPARQL engine. The last one evaluates the SPARQL part of the query on a combination of both, the received window content and possible other static data sources that have to be taken into account during query evaluation. For its implementation, C-SPARQL is making use of Esper for the streaming subsystem, and Apache Jena ARQ for the SPARQL subsystem.
Listing 1.1 shows an example of a C-SPARQL query looking for the location of a ship which is named \ELM K". The query is continuously executed with an interval of 5 seconds and takes into account all observations streamed in the last 60 seconds before execution. The output of the query will consist of the actual
REGISTER STREAM pog AS # p r e f i x e s have been omitted SELECT ?o ?xWKT FROM STREAM <http : / / . . . / sgraph> [RANGE 60 s STEP 5 s ] WHERE f ?o r d f : type caprads : Observation . ?o geo : hasGeometry ?g . ?g geo :asWKT ?xWKT . ?p caprads : p r o p e r t i e s ?p . ?p caprads : shipName \ELM K" .
REGISTER STREAM pog AS # p r e f i x e s have been omitted SELECT ?o ? sn ?xWKT FROM STREAM <http : / / . . . / sgraph> [RANGE 60 s STEP 5 s ] FROM <https : / / datatank . stad . gent /4/ i n f r a s t r u c t u u r / dokken . kml> WHERE f g ?o r d f : type caprads : Observation . ?o geo : hasGeometry ?x . ?x geo :asWKT ?xWKT . ?p caprads : p r o p e r t i e s ?p . ?p caprads : shipName ? sn . ?d r d f : type caprads : Dock . ?d r d f s : l a b e l \ALPHONSE SIFFERDOK" . ?d geo : hasGeometry ?y . ?y geo :asWKT ?yWKT .
FILTER ( g e o f : sfWithin (?xWKT, ?yWKT) )
observation identi er and the geometry of the observed location expressed in the Well-known Text2 (WKT) format.
The black-box architecture of C-SPARQL makes it easy to replace the subsystems with other implementations. To support GeoSPARQL on the C-SPARQL engine, we can easily replace the Jena ARQ subsystem with the Parliament engine which is based on Jena ARQ as well. Due to the modularized implementation of C-SPARQL, integration of the Parliament engine is straightforward. As a result of this integration the C-SPARQL engine becomes capable of handling GeoSPARQL queries over streaming RDF data. We call this extension C-GeoSPARQL.
Listing 1.2 shows an extended version of the C-SPARQL query presented in listing 1.1. The query is now looking for all ships present in the dock labeled as \ALPHONSE SIFFERDOK". Thanks to the parliament integration this can be done using the geof:sfWithin(X, Y) function. This GeoSPARQL function checks if a geometry X, describing a certain area, is located inside geometry Y, where X and Y can be expressed in WKT or in the Geography Markup Language3 (GML). In this particular example query, geof:sfWithin(?xWKT, ?yWKT), checks if the geometry related to the ship observation (?xWKT), is laying within the boundaries of the geometry of the dock (?yWKT).
To practice with C-GeoSPARQL a test environment regarding the port of the
city of Ghent (PoG) was implemented using TripleWave [
Implementation 1. Registration of a (geographic) RDF data stream in the system 2. Getting meta-data about the stream and establishing a websocket connection 3. Receiving the streaming RDF data 4. Registering additional static RDF or KML data sources 5. Registering a C-GeoSPARQL query and wait for results
The geographic data sources, both streaming ship observations and static information about the port, are represented at the right side of gure 2.
An Automatic Identi cation System (AIS) is an automatic tracking system used for collision avoidance on ships and by Vessel Tra c Services (VTS). It produces a continuous stream of detected ships in the area under surveillance. Today the port of Ghent and Zeeland is monitored by a system called Enigma+ (Electronic Network for Information in the Ghent-Zeeland Maritime Area). Unfortunately this platform is not publicly accessible. As an alternative we make use of MarineTra c6 data. MarineTra c is an internet service o ering payed and free services regarding ship tracking. To test the application an o -line dataset with ship movements from MarineTra c is used. The ship observation from MarineTra c are stored on disk and can be replayed with TripleWave to create a stream of data consisting of ship observations.
TripleWave7 is an open-source tool for making RDF streams available to the Web. The aim of the framework is to help creating and publishing streaming RDF data through the Web, in such a way the data can be used in a continuous execution model. The framework is a generic and exible solution that can be used for di erent purposes: (1) transforming streaming data on the web to RDF streams using R2RML mappings; (2) replaying RDF dumps with temporal information; or (3) Replaying RDF data with temporal information exported through a SPARQL endpoint. For the implementation of the use case the second application is used. The stored ship observations from MarineTra c are replayed to create the data streams.
The ship observations from MarineTra c are encoded as GeoJSON8. GeoJSON is a format for encoding a variety of geographic data structures using JavaScript Object Notation (JSON). To be able to use GeoSPARQL to query over the observed geometries, these have to be expressed in WKT or GML format. Listing 1.3 shows how an observation expressed in JSON looks like after serializing the geometry into the WKT format. To annotate the observations semantically and express them in JSON-LD, a context, of which a snapshot is displayed in listing 1.4, is added.
Next to the ship observations, the system also needs information about the location of the docks, the company sites and the quays. This static data about the port is publicly available in the datatank9 of the city of Ghent10. It is a data platform o ering open data about the city of Ghent. The data is publicly available in Keyhole Markup Language (KML) format which is an XML based GIS format. These KML les can easily be displayed on maps. However, conversion is needed to perform semantic integration with the streaming data and other semantic data sources.
TripleGeo11 is an open-source tool for extracting features from les with geospatial data into RDF triples. It has been integrated in the RSP services to 6 http://www.marinetra c.com/ 7 http://streamreasoning.github.io/TripleWave/ 8 https://tools.ietf.org/html/rfc7946 9 http://http://thedatatank.com/ 10 http://datatank.gent.be 11 https://web.imis.athena-innovation.gr/redmine/projects/geoknow public/wiki/TripleGeo f g
g g g
Listing 1.3. Ship Observation \ @context " : f \ s f " : \ http : / /www. o p e n g i s . net / ont / s f #", \ geo " : \ http : / /www. o p e n g i s . net / ont / g e o s p a r q l #", \ caprads " : \ http : / / i d l a b . ugent . be/ caprads / vocab#" , \ xsd " : \ http : / /www. w3 . org /2001/XMLSchema#", \ Feature " : \ geo : Feature " , \ Point " : \ s f : Point " , \ p r o p e r t i e s " : \ caprads : p r o p e r t i e s " , \ geometry " : \ geo : hasGeometry " , \asWKT" : \ geo :asWKT" , \ type " : \@type " , . . .
make it possible to register KML les as static data sources. When this type of data sources are registered at the RSP Service, the RSP Service collects the data and uses TripleGeo to convert it to RDF data that is loaded as static background knowledge into the RSP engine.
At the top left of gure 2, the PoG web interface is visualized. The user interface, a simple web application (Fig. 3), is composed of a map and some I/O text elds. The text eld components are used to load static data sources, register streams and register queries. The map is used to display both, the static geographic data sources and the streaming query results. On the map in the gure 3 for example, we can distinguish docks (blue), company sites (green) and quays (red dots).
The main components of the semantic stream processing unit are displayed at the bottom left of gure 2. The RSP service API o ers simple REST interfaces on top of the underlying RSP engine to help exposing RSP engine capabilities to the Web. It provides di erent interfaces to manage streams, queries and static data sources in the underlying RSP engine. The actual RSP engine is the adapted C-SPARQL engine where the Jena ARQ subsystem has been replaced by the Parliament engine. 4.2
Scenarios Some possible scenarios the application can deal with are: 1. Get all ships:
In this scenario only the streaming ship observations are queried. The query is limited to C-SPARQL features and does not make use of any GeoSPARQL features. # p r e f i x e s have been omitted CONSTRUCT f ? s r d f : type geo : Feature . ? s geo : hasGeometry ?x . ?x geo :asWKT ?xWKT . ? s caprads : p r o p e r t i e s ?p .
?p ? pred ? prop . g FILTER( f : timestamp (? s , r d f : type , ? t ) = ? t s ) FILTER( g e o f : sfWithin (?xWKT, g e o f : b u f f e r (?yWKT, ? radius , ? u n i t ) ) )
2. Get all ships of a certain type present in a certain dock:
This scenario makes use of both streaming ship observations and static information about the docks. Ship observations can be selected based on the gt shiptype property, and ltered making use of the GeoSPARQL function geof:sfWithin(X, Y) where X is the geometry of the observed ship and Y is the geometry of the dock. 3. Get ships in evacuation zone:
By means of example the query for this scenario is shown in listing 1.5. In this query three data sources are used: the stream with ship observations, information about company sites and a le with incidents. An incident can be a re or a kind of leak like an oil or gas leak. Thanks to the RDFS reasoning support of the C-SPARQL engine we can make abstraction of the actual incident type. The incident is related to a company site with the impactedBy property. To determine if ships are in a certain evacuation zone ltering can be performed using the GeoSPARQL functions geof:sfWithin(X, Y) and goef:bu er(X, radius, unit).
In this paper we presented how the C-SPARQL engine, designed for querying RDF data streams, can easily be extended with GeoSPARQL support to allow querying geospatial RDF data streams. To test the solution a use case regarding the port of the city of Ghent was implemented.
Future work includes looking at benchmarking the extended C-SPARQL engine to quantify the impact of the integration with the Parliament library. For this a set of well chosen test queries, that allow us to measure the execution time spent at evaluating the GeoSPARQL functions, has to be de ned. Another thing to look at is integration of geographic stream processing in more advanced semantic visualization tools for geographic data.