In this demo paper we describe an iOS-based application that allows visualizing live bus transport data in Madrid from static and streaming RDF endpoints, reusing the Web services provided by the bus transport authority in the city and wrapping them using SPARQLStream. Data from public administration and services in countries, regions and cities are increasingly made publicly available. However, most of this data is produced and exposed in very heterogeneous formats, represented in di erent models and deployed under diverse technologies. While developers can take advantage of this data, the time taken in understanding the models and formats constitutes a barrier to enable the integration of the di erent data sources needed for a given application. The use of standard vocabularies and data models such as RDF and query languages as SPARQL have proven to be helpful to overcome this semantic heterogeneity. This is also the case with public transportation data in a large city such as Madrid. The local bus transport authority, EMT, provides a set of web services1 that allow retrieving information such as the bus stops, bus lines, routes, stop locations, and other mainly static data. The data is returned by these services as XML documents. For example the following XML response in Listing 1.1 provides the details about a bus stop.
that can be seen as data streams. Moreover, most RDF stream processing engines lack the flexibility of defining mappings between the source schemas and the ontological schema. Of these, only SPARQLStream supports using declarative R2RML mappings3 for doing so. Furthermore, current implementations of RDF stream query engines are hard to access for end-user applications.
In this demo we show how we enabled an iOS tablet application to access both the static and dynamic data from the city of Madrid, and in particular the data from the EMT web services. We showcase the use of an RDF stream SPARQL endpoint (using the Morph-streams4 implementation of SPARQLStream), that can be accessed by the client application in the same way it accesses a static SPARQL endpoint. 2
The architecture of the system is the following (Figure 1): the client application is a
Tablet iOS App that requests static data from a SPARQL endpoint that contains Bus
station data including name, geo-location, etc. With this data, the App can display the
bus stops in a Google Map. The App can also send queries and receive results from a
live SPARQLStream endpoint that provides data about the reported waiting times in each
bus stop. The endpoint is implemented using Morph-streams, that serves virtual RDF
streams through SPARQLStream continuous queries.
The SPARQLStream endpoint runs a live virtual RDF stream that is directly fed from
the Madrid EMT web services. SPARQLStream was first introduced in [
PREFIX ssn: <http://purl.oclc.org/NET/ssnx/ssn#> PREFIX qudt: <http://data.nasa.gov/qudt/owl/qudt#> PREFIX emt: <http://emt.linkeddata.es/data#> SELECT ?waittime ?obs ?stop FROM NAMED STREAM <http://emt.linkeddata.es/data#busstops.srdf> [NOW - 300 S] WHERE { ?obs a emt:BusObservation; ssn:observedBy ?stop.
ssn:observationResult ?result. ?result emt:timeToBusValue ?av.
?av qudt:numericValue ?waittime.
} Listing 1.2. SPARQLStream query requesting waiting times reported in the latest 5 min. 2.2
As we stated before, RDF streams in the system are virtual, so we use mappings to
relate the ontological terms of the SPARQLStream queries to the schema of the original
EMT stream. for this, Morph-streams uses an R2RML set of mappings, as described
in [
Listing 1.3. R2RML sample mappings. 2.3
The Map4RDF iOS App is designed as a general purpose RDF-based application for mobile devices, implemented in Objective-C and targeted to display geo-referenced information from SPARQL endpoints. In this way, the developer needs only to provide the suitable SPARQL queries that fulfill his data needs, and get the results in JSON format. In a first stage the App identifies data categories in a static SPARQL endpoint that can be displayed in a map (e.g. instances of emt:BusStop). The App is able to recognize latitude-longitude coordinates using the WGS84 Geo Positioning vocabulary5 and also WKT points and polygons. The App already has implemented usual features such as layering, bounding box views, clustering of visualized points, etc. that can be applied to the visualized points.
Once the geo-referenceable instances are identified (through their URIs), the App can be configured to retrieve more information from each of these instances when the user clicks over it. In the case of the Bus stop application, it can retrieve the stop name 5 http://www.w3.org/2003/01/geo/wgs84_pos# and description from a static SPARQL endpoint, and the bus waiting times from a streaming SPARQLStream endpoint. For instance, the App can easily display a bus route in the map as in Figure 2. The App also natively recognizes statistical data if available in the RDF dataset (supports the RDF Data Cube Vocabulary6). One of the key features of Map4RDF is that the data retrieval is entirely configurable by the developer, by specifying the SPARQL and SPARQLStream queries and endpoints.
The App is able to relate the static data and the dynamic data thanks to the URIs that link both datasets: e.g. A Bus stop URI in the static endpoint, is referenced by a bus waiting time observation in the streaming endpoint. In this way if the user clicks on a bus stop, a query is launched against the SPARQLStream endpoint, requesting the current waiting times for the stop represented by that URI (Figure 2).
This work has been supported by the PlanetData FP7 257641 Project. We thank EMT Madrid for providing access to their data services. 6 http://www.w3.org/TR/vocab-data-cube/