We address the problem of registering and discovering sensors, sensor services and other related resources in the Semantic Sensor Web. We show how to develop a semantic registry for the storage and manipulation of metadata describing such resources using an implementation of the data model stRDF and the query language stSPARQL. stRDF extends RDF with the ability to represent spatial and temporal metadata using linear constraints. stSPARQL extends SPARQL for querying stRDF metadata. Together they provide a natural modeling framework for the problem at hand, since spatial and temporal metadata gure prominently in the description of sensors and related resources or services. We present Strabon, a storage and query evaluation module for stRDF/stSPARQL for the architecture of the EU FP7 project SemsorGrid4Env and we show how to use Strabon to implement a semantic registry.
Millions of sensors are currently been deployed in sensor networks around the
globe and are actively collecting an enormous amount of data. Together with
legacy data sources, specialized software modules (e.g., modules performing
mathematical modeling and simulation) and current Web 2.0 technologies such
as mashups, deployed sensor networks give us the opportunity to develop unique
applications in a variety of sectors (environment, agriculture, health,
transportation, surveillance, public security etc.). The term Semantic Sensor Web (SSW)
[
Another important activity in this area is the standardization activities of the
Sensor Web Enablement (SWE) Working Group of the Open Geospatial
Consortium (OGC) [
An important component of SSW architectures is the registry which is used
for discovering sensors, sensor services and other related resources. Registries
store metadata about SSW resources and make this metadata available to client
applications. In this paper we discuss the design and implementation of a
semantic registry that is currently being developed in the context of the European
FP7 SSW project SemsorGrid4Env[
The organization of this paper is the following. In Section 2 we present the data model stRDF and the query language stSPARQL by means of examples. In Section 3 we present our current implementation of stRDF/stSPARQL and in Section 4 we present our implementation of a semantic registry. Comparison with related work is presented in Section 5 and in Section 6 we present our conclusions and discuss future work. 2
The first two questions that needed to be answered while developing a registry
for the SSW are: (i) what data model should be used to encode SSW resource
metadata and (ii) what query language should be used to facilitate the discovery
of SSW resouces. As first pointed out in [
In [
To develop stRDF, we follow closely the ideas of constraint databases and
especially the work on CSQL [
Linear constraints. Constraints will be expressed in the first-order language L = {≤, +} ∪ Q over the structure Q = ⟨Q, ≤, +, (q)q2Q⟩ of the linearly ordered, dense and unbounded set of the rational numbers, denoted by Q, with rational constants and addition. The atomic formulae of this language are linear equations and inequalities of the form: ∑p
i=1 aixiΘa0, where Θ is a predicate among =, or ≤, the xi’s denote variables and the ai’s are integer constants. Note that rational constants can always be avoided in linear equations and inequalities. The multiplication symbol is used as an abbreviation i.e., aixi stands for xi + · · · + xi (ai times).
We now define semi-linear subsets of Qk, where k is a positive integer. De nition 1. Let S be a subset of Qk. S is called semi-linear if there is a quantifier-free formula ϕ(x1, . . . , xk) of L where x1, . . . , xk are variables such that (a1, . . . , ak) ∈ S iff ϕ(a1, . . . , ak) is true in the structure Q.
We will use ∅ to denote the empty subset of Qk represented by any inconsistent formula of L.
C1 ∪ C2 ∪ · · · .
The sRDF data model. As in theoretical treatments of RDF [
In the above definition, the standard RDF notion of a triple is extended, so that the object of a triple can be a quantifier-free formula with linear constraints. According to Definition 1 such a quantifier-free formula with k free variables is a finite representation of a (possibly infinite) semi-linear subset of Qk. Semi-linear subsets of Qk can capture a great variety of spatial geometries, e.g., points, lines, line segments, polygons, k-dimensional unions of convex polygons possibly with holes, thus they give us a lot of expressive power. However, they cannot be used to represent other geometries that need higher-degree polynomials e.g., circles. Example 1. The following are sRDF triples: ex:s1 rdf:type, ex:Sensor . ex:s1 ex:has_location "x=10 and y=20"^^strdf:SemiLinearPointSet The above triples define a sensor and its location using a conjunction of linear constraints. The last triple is not a standard RDF triple since its object is an element of set C.
In terms of the W3C specification of RDF, sRDF can be realized as an
extension of RDF with a new kind of typed literals: quantifier-free formulae with
linear constraints (we will usually call them spatial literals). The datatype of
these literals is e.g., strdf:SemiLinearPointSet (see Example 1 above) and
can be defined using XML Schema. Alternatively, linear constraints can be
expressed in RDF using MathML1 and serialized as rdf:XMLLiterals as in [
The stRDF Data Model We will now extend sRDF with time. Database researchers have differentiated among user-defined time, valid time and transaction time. RDF (and therefore sRDF) supports user-defined time since triples are allowed to have as objects literals of the following XML Schema datatypes: textttxsd:dateTime, xsd:time, xsd:date, xsd:gYearMonth, xsd: gYear, xsd:gMonthDay, xsd:gDay, xsd:gMonth.
stRDF extends sRDF with the ability to represent the valid time of a triple
(i.e., the time that the triple was valid in reality) using the approach of Gutierrez
et al. [
The time structure that we assume in stRDF is the set of rational numbers Q (i.e., time is assumed to be linear, dense and unbounded). Temporal constraints are expressed by quantifier-free formulas of the language L defined earlier, but their syntax is limited to elements of the set C1. Atomic temporal constraints are formulas of L of the following form: x ∼ c, where x is a variable, c is a rational number and ∼ is <, ≤, ≥, >, = or ̸=. Temporal constraints are Boolean combinations of atomic temporal constraints using a single variable.
The following definition extends the concepts of triple and graph of sRDF so that thematic and spatial data with a temporal dimension can be represented. De nition 3. An stRDF quad is an sRDF triple (a, b, c) with a fourth component τ which is a temporal constraint. For quads, we will use the notation (a, b, c, τ ), where the temporal constraint τ defines the set of time points that the fact represented by the triple (a, b, c) is valid in the real world. An stRDF graph is a set of sRDF triples and stRDF quads. 2.2
We present the syntax of stSPARQL by means of examples involving sensor
networks. More examples of stSPARQL are given in [
We consider a dataset that describes static and moving sensors and uses
the CSIRO/SSN Ontology [
The stRDF description of a static sensor that measures temperature and has a certain location is the following (ssn is the namespace of the CSIRO/SSN ontology and ex an example ontology): ex:sensor1 rdf:type ssn:Sensor . ex:sensor1 ssn:measures ex:temperature . ex:temperature ssn:type ssn:PhysicalQuality . ex:sensor1 ssn:supports ex:grounding1 . ex:grounding1 rdf:type ssn:SensorGrounding . ex:grounding1 ssn:hasLocation ex:location1 . ex:location1 rdf:type ssn:Location . ex:location1 strdf:hasGeometry
"x=10 and y=10"^^strdf:SemiLinearPointSet .
Let us now present an example of modeling moving sensors in stRDF. Trajectories of moving sensors are represented by semi-linear sets of dimension 3 in variables x, y, and t. ex:sensor2 rdf:type ssn:Sensor . ex:sensor2 ssn:measures ex:temperature . ex:sensor2 ssn:supports ex:grounding2 . ex:grounding2 rdf:type ssn:SensorGrounding . ex:grounding2 ssn:hasLocation ex:location2 . ex:location2 rdf:type ssn:Location . ex:location2 strdf:hasTrajectory "(x=10t and y=5t and 0<=t<=5) or
(x=10t and y=25 and 5<=t<=10)"^^strdf:SemiLinearPointSet. Finally, we assume that we have the stRDF descriptions of some rural area where the sensors are deployed. The stRDF description of such an area called Paros is: ex:area1 rdf:type ex:RuralArea . ex:area1 ex:hasName "Paros" . ex:area1 strdf:hasGeometry "(-10x+13y<=-50 and y<=79 and y>=13 and x<=133) or (y<=13 and x<=133 and x+2y>=129)"^^strdf:SemiLinearPointSet .
Example 2. Spatial selection. Find the URIs of the static sensors that are inside the rectangle R(0,0,100,100)? select ?S where {?S rdf:type ssn:Sensor . ?G rdf:type ssn:SensorGrounding . ?L rdf:type ssn:Location . ?S ssn:supports ?G . ?G ssn:haslocation ?L . ?L strdf:hasGeometry ?GEO .
filter(?GEO inside "0<=x<=100 and 0<=y<=100")}
Let us now explain the new features of stSPARQL by referring to the above
example. In stSPARQL, variables can be used in basic graph patterns to
refer to spatial literals denoting semi-linear point sets. They can also be used in
spatial filters, a new kind of filter expressions introduced by stSPARQL that
is used to compare spatial terms using spatial predicates. Spatial terms
include spatial constants (finite representations of semi-linear sets e.g., "0<=x<=10
and 0<=y<=10"), spatial variables and complex spatial terms (e.g., ?GEO INTER
"x=10 and y=10" which denotes the intersection of the value of spatial
variable ?GEO and the semi-linear set "x=10 and y=10"). There are several types of
spatial predicates such as topological, distance, directional, etc. that one could
introduce in a user-friendly spatial query language. In the current version of
stSPARQL only the topological relations of [
Example 3. Intersection of an area with a trajectory. Which areas of Paros were
sensed by a moving sensor and when?
select (?TR[
?RA strdf:hasGeometry ?GEO . filter(?TR[
Example 4. Projection and spatial function application. Find the URIs and the locations of the sensors that are north of Paros. Encode the locations in WKT. select ?SN ToWKT(?SN_LOC) AS ?WKT_LOC where {?RA rdf:type ex:RuralArea . ?RA ex:hasName "Paros" . ?RA strdf:hasGeometry ?GEO . ?SN rdf:type ssn:Sensor . ?X rdf:type ssn:SensorGrounding . ?Y rdf:type ssn:Location . ?SN ssn:supports ?X . ?X ssn:hasLocation ?Y .
?Y strdf:hasGeometry ?SN_LOC.filter(MAX(?GEO[
In this section we present Strabon, a storage and query evaluation module for
stRDF/stSPARQL which is currently under development by our group in the
context of project SemsorGrid4Env [
Query Engine
Parser Optimizer Evaluator Transaction Manager Storage Manager
Repository
SAIL RDBMS
Constraint Engine
Representation
Translator semi-linear sets of dimension at most 2 (i.e., only spatial data in 2 dimensions are supported). This is a realistic scenario that allows us to capture all the spatial data of SemsorGrid4Env (e.g., spatial coverage for data sources exposing UK’s national Spatial Data Infrastructure datasets, programmatic data and commercial product datasets). Once our first prototype is complete and has been thoroughly evaluated, we will turn our attention to the full data model. 3.1
Strabon is built on top of the well-known RDF store Sesame [
The Sesame architecture consists of the following layers (some of which are shown in Figure 1 in the context of the Strabon architecture): Access APIs and Storage and Inference Layer (SAIL) APIs. The most important Access API is the Repository API that is used for querying and updating data. SAIL is the layer below the Access APIs. SAIL API’s role is to offer storage support to the entire application, while the Repository API mentioned above just provides transparent access to SAIL. SAIL provides RDF-specific methods to access RDF data that are translated to calls to the underlying database.
We stress that although a new generation of RDF stores recently proposed by
the database community [
Figure 1 presents the system architecture of Strabon which consists of the following modules: { Query Engine: This module is used to evaluate stSPARQL queries posed by clients. The Query Engine receives all the stSPARQL queries, parses them, optimizes them, prepares an execution plan and returns the appropriate response to the client. We have extended Sesame’s Parser and Evaluator to handle stSPARQL queries and use Sesame’s Optimizer and Transaction Manager as is. In Section 3.3 we describe how the Query Engine evaluates stSPARQL queries. { Storage Manager : This module is responsible for storing data in the underlying PostGIS database. The Repository, SAIL and RDBMS layers are Sesame’s modules that were described above. We have extended the RDBMS layer to be able to store spatial literals in PostGIS. In Section 3.2 we provide more details about the Storage Manager. { PostGIS : Strabon uses PostGIS to store stRDF data and to perform part of the query evaluation process as we will show in Section 3.3. { Constraint Engine: This module is responsible for processing the part of the stSPARQL queries that deal with geometries and the conversions that take place during data loading. Since we want our implementation to cater for the case that input spatial objects are expressed in other spatial data models (e.g., using OGC standards), the Representation Translator component has been introduced to translate spatial objects between the constraint and other equivalent representations. Spatial objects that represent non-convex geometries are convexified prior to storage to take advantage of efficient computational geometry algorithms for convex geometries. This is the job of the Convex Partitioner module. The Normal Form Constructor takes the output of the Representation Translator or the Convex Partitioner and constructs a geometry in a normal form that we describe in Section 3.2 below. 3.2
When a user wants to store stRDF data, she makes them available in the form of an stRDF document. The document is decomposed into stRDF triples and each triple is stored in the underlying repository as we explain below.
Sesame supports two storage schemes for pure RDF data. A “monolithic” scheme where all triples are stored in a giant Triple table, and a vertical partitioning scheme that stores triples using one table per predicate. In both cases, the data is stored using dictionary encoding i.e., each URI or literal is encoded by a unique positive integer to reduce space. The mapping between the original RDF term and its encoding is stored in a separate table.
In Strabon, the storage scheme of Sesame is extended with an extra table that stores detailed information about spatial literals. In addition, spatial literals are encoded using the same dictionary encoding techniques. If the “monolithic” storing scheme is used, all stRDF triples are stored in the Triple table. The schema of the Triple table is Triple(subj id integer, pred id integer, obj id integer) and each tuple has a subj id (resp. pred id, obj id ) that is the unique encoding of the triple’s subject (resp. predicate, object).
An additional table SpatialLiteral is used to store information about spatial literals. The schema of the table is SpatialLiteral(id integer, value varchar, strdfgeo geometry). Each tuple in the SpatialLiteral table has an id that is the unique Geometric objects represented with
constraints Geometric objects represented with Well Known Text (WKT) points, lines, polygons, TINs and polyhedrons
Repository
SAIL RDBMS
Constraint Engine
Representation Translator proIncpeusstor cddlib prOocuetpsustor
Convex Partitioner proIncpeusstor CGAL prOocuetpsustor rom tro laF trc
u roNm sonC
PostGIS encoding of the spatial literal. The string representation of the spatial geometry is stored in the value attribute. The attribute strdfgeo is a spatial column whose data type is the PostGIS-defined geometry type and is used to store the geometric object that is described by the spatial literal. The stored object is the vector representation of a semi-linear point set in normal form. In the case that the vertical partitioning scheme of Sesame is used, the same additions are done to it to facilitate the storage of stRDF data.
In the rest of this section we will describe in detail the conversions that take place during data loading and how we populate the table SpatialLiteral. Prior to storing geometries, we process the input geometries provided by the users so that each geometric object that we consequently store in PostGIS is in a normal form that satisfies the following requirements: { Constraints have been transformed to the equivalent vector representation. { The geometry is expressed as the union of convex components. { There are neither redundant nor inconsistent geometries. { The geometries are stored in a specific order to speed-up the conversion between the vector and constraint representation.
Let us now describe in detail how data are converted in normal form. When
a user wants to store a spatial literal, the RDBMS layer of the Storage Manager
initiates the procedure of converting the input geometry to normal form and
storing it to PostGIS. When the input geometry is represented with constraints,
the Storage Manager communicates with the Representation Translator to
convert these constraints to disjunctive normal form (DNF) so that each geometry is
expressed as a disjunction of conjunctions of constraints. Since each conjunction
of constraints represents a convex spatial object, the DNF form is equivalent to
a union of convex spatial objects. Subsequently, the Representation Translator
converts the constraint representation of the geometry to the equivalent vector
representation using Fukuda’s cddlib library [
Our implementation also supports geometries expressed in the OGC
WellKnown Text (WKT) specification2. In this case, the RDBMS layer of the Storage
Manager communicates with the Constraint Engine, which normalizes the input
geometry, but a different procedure is followed. Specifically, the Convex
Partitioner simplifies the user input so that non-simple polygons are converted to
a list of simple polygons. Each non-convex simple polygon is partitioned into
convex sub-partitions using CGAL [
The implementation described above has been heavily influenced by the
implementation of D´edale [
Another important module of Strabon is the query engine. The design of the query engine is classical and is illustrated in Figure 3. It consists of a parser, an optimizer, a query processor (evaluator) and a transaction manager. The parser extends Sesame’s parser to parse stSPARQL queries. The parser generates a query model that will be optimized later on by the optimizer. In the version of Strabon currently under development, the Sesame optimizer and transaction manager are used essentially as is. Later versions will deal with the new features of stSPARQL. Sesame’s optimizer consists of a set of heuristics that rearranges the order of the query’s triple patterns so that the query will be evaluated more efficiently. Sesame’s evaluator has been extended so that it takes as input the optimized model of the query and evaluates it in a streaming fashion by taking into account the new features introduced by stSPARQL.
An stSPARQL query is evaluated as follows: In the first step, in which most of the processing takes place, the stSPARQL query is transformed to an SQL query by the evaluator depending on the storage being used. For example, the 2 Although stRDF/stSPARQL is based on linear constraints, it is our intention that Strabon enables the processing of spatial data represented in common OGC formats, supported by popular DBMS or GIS. In fact, this need has arisen in SemsorGrid4Env where we have to import geometries expressed in WKT that described the spatial coverage of stored and stream data sources.
stSPARQL query
Parser Optimizer Evaluator Transaction Manager
Representation
Translator Convex Partitioner spatial filters of the stSPARQL query are mapped to the equivalent built-in functions and operators of PostGIS. Afterwards, Sesame evaluates the SQL query via PostGIS. The results of this query are returned to the evaluator which performs some post-processing to the results. For example, it calculates the result of expressions that may exist in the SELECT clause of the stSPARQL query, such as the construction of new spatial terms, using the results that have been retrieved from PostGIS in the previous step. The last step of the query processing involves displaying the final results in the format specified by the user. In the default case, results are encoded according to the SPARQL Query Results XML Format recommendation and the constraint representation is used for spatial data. The user can also request that the spatial literals are encoded using OGC’s Well Known Text representation. Finally, the user can also retrieve the results encoded in Keyhole Markup Language (KML) which is an OGC standard and is widely used in the mapping industry. 4
In this section, we provide a brief description of the project SemsorGrid4Env and a synopsis of the proposed conceptual Web service architecture. Besides that, our main goal is showing how Strabon can be used to implement the Semantic Registry of the SemsorGrid4Env architecture. 4.1
The project “Semantic Sensor Grids for Rapid Application Development for Environmental Management (SemsorGrid4Env)”, aims to realize the SSW vision by developing a software platform which allows the rapid development of open large-scale semantics-based applications over data sources such as sensor networks that provide real-time information, and traditional data sources such as relational databases that may provide historical data, simulation data etc. The results of the project are demonstrated in two use cases: “Fire Risk Monitoring and Warning in NorhtWest Spain” and “Coastal and Estuarine Flood Warning in Southern UK”.
The SemsorGrid4Env service-oriented architecture [
Semantic Integrator Application Services Data Source Connectivity
Bridge Concrete Resource
Semantic Registry
Semantic Registry
Service Registration
Query
Strabon
Query
Engine
Constraint
Engine
Storage
Manager
PostGIS
Tier, a Middleware Tier and a Data Tier. The Application Tier comprises
services that provide domain specific functionality to consumers and applications.
For example, an application may enable a user to visualize a layer on a map,
displaying temperature or tide height in a selected area. The Middleware Tier
consists of two main services: the Semantic Registry (also called the Semantic
Registration and Discovery service), a service that can be accessed by
prospective clients who want to manage thematic and spatial metadata about sensors,
sensor networks, data sources, etc. and the Semantic Integration service that
virtualizes multiple data sources with the use of semantic technologies [
The Semantic Registry enables the registration of SSW resources, such as sensors, sensor networks, streaming data sources with real-time data and stored data sources with historical data. These resources can then be discovered using thematic and spatial criteria, and subsequently be used in other services or applications like mashups.
Figure 4 depicts how Strabon is used to realize the Semantic Registry of the SemsorGrid4Env arhitecture. Strabon lies between clients i.e., metadata providers or metadata consumers, and PostGIS, that stores the metadata provided by metadata providers. Metadata providers intend to make public their resources by registering them with the registry, while metadata consumers aim to discover specific data resources based on criteria specific to them. The components of the SemsorGrid4Env architecture play the roles of metadata providers or consumers. A data source is a metadata provider that may produce metadata about the stream or stored data exposed via its interfaces. The Semantic Integrator may be either a metadata consumer or a metadata provider. It may query the registry to discover data sources with specific characteristics, semantically integrate them in a new virtual data source and then store the description of the new virtual data source to the registry. Applications may also be metadata providers or metadata consumers. Applications may use the registry to discover data sources that meet their needs, or publish data sources that reside outside the context of SemsorGrid4Env, such as OGC’s SWE services.
The list of interfaces exposed by the Semantic Registry that are mandatory
for its operation are depicted in Figure 4. Specifically the service consists of the
following interfaces:
{ Service Interface. This interface enables clients to “make well-informed and
well-formed interactions” [
We have not so far defined any interface that allows harvesting of resource
metadata as in other approaches [
Let us now give examples of the SemsorGrid4Env software platform functionality, focusing on the interactions of various components with the Semantic Registry for registering and discovering data sources.
Suppose that a user wants to expose sensed data of wind speed and
predicted values of wave height in the area of Southampton using a Stored Data
Service, and another user wants to register a service providing the scheduled
ship departure times from the ports of England. The users use the ontologies
that have been developed in the context of SemsorGrid4Env to create
semantically enriched property documents that contain thematic and spatial metadata
about the exposed data sources. These ontologies include, among others, a
sensor network and observation ontology, a domain-specific ontology describing the
concept of flood and an ontology describing the content of a dataset exposed by
a service (e.g., the dataset’s spatial coverage, its structure, etc) [
Let us suppose now that an end-user is looking for a Stored Data Service that observes tide height or wave height and partially covers South England. The user may utilize a mashup application that transforms the user’s request in an stSPARQL query with the appropriate thematic and spatial restrictions. This query is transmitted through the Semantic Registry to Strabon encapsulated inside a SparqlExecute request, where it is evaluated. The result of this query is returned to the mashup application and is presented to the user.
Similarly, a domain expert may be interested in exposing a source targeted at more specialized audiences. Specifically, she may want to associate the wave height with the ship departure times from Southampton, so that potential hazards for the ships may be discovered. To accommodate these specialized needs, she can use the Semantic Integrator to create a “virtual” data source that unifies these data sources. The new data source is registered with the registry in the same way, and can be discovered in a way identical to the scenario above. 5
There have been several approaches to developing registries for SSW architectures. Below we discuss the most relevant to our work.
In the context of OGC SWE, the functionality of a registry can be realized by some component that implements the OGC catalogue service specification. The common query language developed for interoperability in this specification is based on attribute-value pairs (data model) and Boolean attribute operator value expressions (queries). In SemsorGrid4Env, we rely on stRDF and stSPARQL i.e., a semantics-based data model and query language that is more expressive than the ones offered by OGC catalogues.
In their initial paper on the SSW [
The SenseWeb/SensorMap project of Microsoft Research provides a common
platform for users to easily publish their sensor data and enable queries over
live sensor data sources. The SenseWeb platform uses as a registry a relational
database, called GeoDB, to store sensor metadata (e.g., publisher name, sensor
location, sensor name, sensor type, data type, unit, sensor data access methods
and free text descriptions) [
The Swiss Experiment (SwissExp) [
The SANY Sensor Anywhere - IST FP6 Integrated Project3 is developing a service-oriented infrastructure for sensor networks and services specific for environmental applications. The registry of the SANY architecture behaves as a cascading catalogue where various underlying data sources may be accessed. It is based on the ORCHESTRA Catalogue Service which is a geospatial catalogue service with a semantically-enriched interface which can be adjusted to any application-specific domain. The ORCHESTRA catalogue service acts like a broker that mediates the client requests to the underlying catalogue protocols such as an other SANY or ORCHESTRA catalogue, a web search engine or various OGC protocols.
The European FP6 project OSIRIS has developed a Sensor Instance Registry
(SIR) that offers operations for inserting, harvesting and querying information
about sensor instances [
We presented the design and implementation of a registry for registering and
discovering sensors, sensor networks and other related SSW resources in the
context of project SemsorGrid4Env. Our future work concentrates on evaluating
our implementation of Strabon and comparing it with competitive approaches
such as [