Current methods and tools that support Linked Data publication have mainly focused so far on static data, without considering the growing amount of streaming data available on the Web. In this paper we describe a case study that involves the publication of static and streaming Linked Data for bike sharing systems and related entities. We describe some of the challenges that we have faced, the solutions that we have explored, the lessons that we have learned, and the opportunities that lie in the future for exploiting Linked Stream Data.
The process of publication of a dataset as Linked Data is composed of several activities:
specification, modeling, generation, publication, and exploitation [
The representation of streaming data following the principles of Linked Data facilitates its integration to the diverse datasets in the Linked Data cloud, and also to other private Linked Data datasets. Streaming data usually coexists with static data, either because there is static data associated with the sensors that produce data streams, usually in the form of descriptive information on the sensor platform and observations (e.g., platform name, location, observed property), or because there are links to static data published in another dataset. Additionally, user requirements may be related to statistics on streaming data that have been accumulated over time, so historical streaming data needs to be considered in the di erent steps of linked stream data publication.
In this paper we report on our experience on exposing as Linked Data some static and dynamic data available in the Spanish cities of Leo´ n and Zaragoza. More specifically, we have focused on static data about points of interest, available from Government open data portals, and on dynamic data about bicycle sharing systems.
Several bicycle sharing systems in cities all over the world have made their data available on the Web. Bike rental stations are distributed in di erent points in the city and the bike sharing systemusually allows users to pick up a bike at any station and drop it o at any (other) station. The goal of this case study is to publish and exploit up-to-date Linked Data about the availability of bikes and free slots in the stations, and links to related resources like travel guides and points of interest (e.g., museums, restaurants).
At this first stage, we are using the data rendered by the services provided by the
CityBikes API1, focusing on the bike sharing systems from the Spanish cities of Leo´n
and Zaragoza. Besides, we have connected this streaming data to static data from open
data portals from these cities, on museums and libraries (for Leo´n), and on restaurants
(for Zaragoza), and to data about travel guides from El Viajero [
In this case study, we followed a process inspired by the method proposed in [
The data sources selected for this case study were related to resources that could be useful to locals and visitors that use bike sharing systems in the di erent cities.
The data for bike sharing systems were obtained in JSON through the CityBikes API. Data for restaurants, museums, libraries and guides is published in RDF by open data portals from the cities of Leo´n and Zaragoza2. While data from Zaragoza was generally of high quality, we found some problems with data from Leo´n, namely: invalid URIs, points of interest that were either not geo-located or with a geo-position but no location name, di erent coordinate systems for geographic positions, and timestamps that did not represent the timezone where they were located. After some interactions, these problems were corrected by the data providers themselves; this shows that data reuse can help in the curation of data sources. In the case of the di erent coordinate systems, the inconsistency was solved during the RDF generation step. 3.2
We have built the citybikes ontology network3 to represent knowledge related to available bikes and free slots in bike sharing systems. These measurements represent the state of a bike station in a particular place and time and are measured through a sensor in each station. The citybikes ontology network follows a modular structure consisting
2 http://www.datosabiertos.jcyl.es/, http://www.zaragoza.es/ciudad/risp/ 3 http://transporte.linkeddata.es/files/citybikesontologynetwork.zip
Identifiers dcterms id
Observatins avaiable bikes
free slots Geopositions wgs84_pos latitude and longitude
Geonames geonames
Bike Systems
bicy located date and time Timestamps
Time ssn values Quantities
qudt of a central ontology that is related to a set of ontologies that describe the di erent sub-domains involved in the modelling of the bike station measurements (Figure 1).
The central ontology is the bike sharing system ontology, which contains concepts such as the bike system and its name, the station and its name, number, internal id, status, description, number of boxes, free slots and free bikes. We reuse the following ontologies: Semantic Sensor Network4 for sensors and observations, Geonames5 to define the location of the systems and the stations based on their latitude and longitude, W3C time ontology6 to represent the timestamp as an instant, Dublin Core7 for identifiers, WGS 848 for geo positioning bike sharing systems and stations with latitude and longitude, and QUDT9 for the number of available bikes and free slots.
Once the ontology was developed, we defined a resource naming strategy to ensure that every class in the ontology can have individuals with unique identifiers (i.e., URIs). For this, it was necessary to identify the cardinalities of the properties in the ontology, since information on the “conceptual schema” of the data sources was not explicit. 3.3
In our use case and in sensor applications in general, we require publishing and consuming stored and streaming data. The first type, also referred to as static, is often related to the metadata and contextual information about sensor data, including geographical location, sensor and station characteristics, observed features, and also includes data
5 http://www.geonames.org/ontology# 6 http://www.w3.org/2006/time# 7 http://purl.org/dc/terms/ 8 http://www.w3.org/2003/01/geo/wgs84_pos 9 http://qudt.org/
SPARQL
RDF
Store SPARQL-Stream
RDF Generation ODEMapster R2RML
Mappings SPARQL-Stream
Processor
Query Rewriting Results Delivery
Static Data Dynamic Data c it y b i. k e s Stream Query
Processing GSN about points of interest (museums, libraries, etc.). Streaming data, in contrast, are highly dynamic and are centered on the observations of free slots and available bikes.
For static data, there are methods and tools for generating RDF and publishing them as Linked Data. Some of these tools generate the RDF data using declarative mappings such as R2RML10 from relational databases, in bulk load operations. This approach is e ective for static data, as it is seldom updated. However, for the dynamic sensor observations and for performing continuous queries, this is not the case. The available tools are unsuitable for materializing data in real time, and even if they were, the SPARQL query language does not consider streaming data operators such as time windows.
Therefore, we used a di erent approach (see Figure 2), based on the idea of reusing
streaming sensor data processing engines, that are able to process highly dynamic data
e ciently, and using temporal constructs. In order to use such engines, we rely on
ontology-based query rewriting of SPARQL queries with streaming extensions. We
used one such extension, SPARQLStream [
When defining the R2RML mappings it was sometimes necessary to define an object map that has a join condition specifying a child and a parent triples map. As the 10 W3C RDB2RDF Mapping Language: http://www.w3.org/TR/r2rml/ 11 ODEMapster RDB2RDF Tool: http://neon-toolkit.org/wiki/ODEMapster generated RDF property flows from child to parent, it was sometimes necessary to define an inverse property in the ontology only for this purpose. This is the case of the property isStationOf which is the inverse of the property hasStation.
An interesting requirement in our use case is the possibility of accessing historical data from the dynamic observations. In order to perform data analysis or compare live data with historical records, we cannot directly use the SPARQLStream approach as it stands, because it only considers recent observation values. As an alternative, we chose to use the live SPARQLStream service in order to periodically pose CONSTRUCT queries that generate RDF triples, which can be later imported to the static RDF store. Then, users requiring statistical or analysis queries, can directly use such a store.
The linking activity was completed with the Silk platform [
Care was taken to ensure that the publication technologies satisfy the licensing and access policies previously defined. 3.4
Queries can be posed against static data, dynamic data, and a combination of both.
For dynamic data there is no RDF data generation; instead, queries are rewritten by
a SPARQLStream processor, to the underlying stream processing engine which throws
the query results. Our SPARQLStream processor can not yet construct in an optimised
manner queries that combine streaming and static data, and this is a pending task for
which we will adopt some existing strategy [
Some of the main challenges that we have faced in the process of producing and
exploiting data in the context of this case study are:
– The SSN ontology has been applied to the domain of bike sharing systems, which
falls outside areas where the SSN ontology has been extensively used, such as
environmental measurements and agriculture. The ontology has proven to be useful
12 http://www.oeg-upm.net/index.php/es/downloads/172-map4rdf
13 http://transporte.linkeddata.es/
to model the observations and measurements. However, for people not used to the
Observation and Measurements approach, which underlies the SSN ontology, this
type of modelling is complex to understand. Clear descriptions of usage patterns
are needed so that the SSN ontology can be more easily exploited by developers.
– For ontology developers, the SSN ontology still poses some challenges when it has
to be extended. For instance, the treatment of properties that are measured by
sensors is represented through a class, and when it needs to be extended, it is sometimes
unclear how this extension has to be done (e.g., using a subclass or an instance) and
it is unclear how properties can be modelled for better reuse across other ontologies
and domains.
– There is a need to explore when it makes sense to follow a native RDF stream
approach to deal with stream data (e.g., as done in [
This work has been supported by the Ciudad2020 INNPRONTA project (IPT-20111006). We want to thank Boris Villazo´n-Terrazas and Freddy Priyatna for their help during the RDF generation process.