The Web of Data currently comprises ≈ 62 billion triples from more than 2,000 different datasets covering many fields of knowledge3. This volume of structured Linked Data can be seen as a particular case of Big Data, referred to as Big Semantic Data [4]. Obviously, powerful computational configurations are traditionally required to deal with the scalability problems arising to Big Semantic Data. It is not surprising that this “data revolution” has competed in parallel with the growth of mobile computing. Smartphones and tablets are massively used at the expense of traditional computers but, to date, mobile devices have more limited computation resources. Therefore, one question that we may ask ourselves would be: can (potentially large) semantic datasets be consumed natively on mobile devices? Currently, only a few mobile apps (e.g., [1, 9, 2, 8]) make use of semantic data that they store in the mobile devices, while many others access existing SPARQL endpoints or Linked Data directly. Two main reasons can be considered for this fact. On the one hand, in spite of some initial approaches [6, 3], there are no well-established triplestores for mobile devices. This is an important limitation because any potential app must assume both RDF storage and SPARQL resolution. On the other hand, the particular features of these devices (little storage space, less computational power or more limited bandwidths) limit the adoption of semantic data for different uses and purposes. This paper introduces our HDTourist mobile application prototype. It consumes urban data from DBpedia4 to help tourists visiting a foreign city. Although it is a simple app, its functionality allows illustrating how semantic data can be stored and queried with limited resources. Our prototype is implemented for Android, but its foundations, explained in Section 2, can be deployed in any other platform. The app is described in Section 3, and Section 4 concludes about our current achievements and devises the future work.
Our approach for managing RDF is inspired by the role played by SQLite5 in Android devices. SQLite is a self-contained SQL engine which is deployed as 3 Stats reported by LODStats: http://stats.lod2.eu/. 4 http://dbpedia.org/. 5 http://www.sqlite.org/. an internal component of the application program. This way, the app itself can read and write data directly from the database files without requiring a separate process running as a DBMS (Database Management System).
Similarly, our only requirement is to hold properly serialized RDF files and a
standardized interface to operate on them. Both responsibilities are provided by
the RDF/HDT [
HDTourist is a proof-of-concept app7 built on top of RDF/HDT. It is designed as a lightweight app to provide tourists with information when they are in a foreign place. In these cases, people are more reluctant to connect to Internet because of the potentially expensive costs of roaming. Thus, our mobile device will be useful to keep compressed semantic information and query it offline. Use case. Let us suppose that we plan our trip to Riva del Garda to attend ISWC’2014, and our flight arrives to Verona. Fortunately, we have a day to visit the city and decide to use HDTourist. Before leaving home, or in a Wi-Fi hotspot (i.e. in the hotel), we use our Internet connection to download the RDF/HDT file with relevant information about Verona. Currently, these data are obtained by exploring different categories related to the DBpedia entity modeling the city: http://dbpedia.org/page/Verona. In addition to semantic data, we can download multimedia: images, maps of the region, etc. to improve the user experience. We download them and HDTourist is ready to be used in our visit.
Verona’s HDT file has 18, 208 triples, with a size of ≈850 KB, more than 4 times smaller than the original NTriples file (≈3.6 MB). Beyond the space savings, this HDT file is self-queryable in contrast to the flat NTriples serialization. 3.1
DBpedia contains a lot of descriptive data about cities, which we filter as follows: given the URI u of a city (e.g. http://dbpedia.org/page/Verona), we run a CONSTRUCT query on DBpedia which retrieves: i) all triples describing the city, i.e., all triples comprising u as subject, and ii) all landmarks related to the city, i.e., all resources (and their descriptions) linking to u. We restrict to resources of some kind of landmarks that we have manually identified, e.g. resources of type Place (http://dbpedia.org/ontology/Place), Historical Buildings (http://dbpedia.org/ontology/HistoricPlace), etc. Other types specifically related to the city are considered, for instance the squares in Verona (http://dbpedia.org/class/yago/PiazzasInVerona).
The RDF subgraph returned by this CONSTRUCT query is then converted to RDF/HDT and ready to be downloaded and queried by our mobile app. 6 We use the Java RDF/HDT library: https://github.com/rdfhdt/hdt-java. 7 Available at: http://dataweb.infor.uva.es/project/hdtourist/?lang=en. 3.2
HDTourist uses categories to organize and display data. The main menu comprises four categories: description, demography and geography, attractions, and other interesting data. Figure 1 (a) shows the description of Verona, which includes basic information about the city. The information showed in each category is defined as SPARQL templates in XML configuration files (one per category), such as the following one: <<?cxamtelgovreyrsiiodn==""A 1t .t0r "a c teniocnosd"i>ng=" u t f - 8 " ?> <name>A t t r a c t i o n s</name> <group> <name>Squares</name> <s p a r q l> SELECT ? l a b e l WHERE { ? p l a c e r d f : t y p e <h t t p : // dbpedia . org / c l a s s / yago / SquaresIn ${CITY}> .
? p l a c e r d f s : l a b e l ? l a b e l .} UNION { ? p l a c e r d f : t y p e <h t t p : // dbpedia . org / c l a s s / yago / PiazzasIn ${CITY}> . } ? p l a c e r d f s : l a b e l ? l a b e l .} </ s p a r q l> </ group> <group> . . . . <name>B u i l d i n g s</name>
This XML excerpt corresponds to Figure 1 (b) showing the category “Attractions”, which includes Squares, Buildings, etc. Each group retrieves the label of attractions with a SPARQL query which typically consists of a UNION of Basic Graph Patterns searching for certain types of resources, as shown in the excerpt. When parsing the XML, the template ${CITY} is converted to the appropriated name, e.g. Verona. Each SPARQL query is then resolved making use of the query API of RDF/HDT, retrieving the label shown in the screen layout.
As shown in Figure 1 (c), each landmark can be expanded, obtaining further information. In this screenshot, we choose the “Piazza delle Erbe” (within “Squares”), and the app retrieves the triples describing it. The concrete information to be shown in the landmark description is also configured by means of an XML file containing one SPARQL template per category, again resolved against the local RDF/HDT. As shown in the screenshot, pictures can be downloaded and stored offline. Finally, HDTourist is able to show geolocated landmarks in interactive maps, as shown in Figure 1 (d) for “Piazza delle Erbe”. The app uses Google maps by default, but offline maps8 can be downloaded beforehand. 4
The offline capacities and structured information consumption possibilities of mobile devices are still several order of magnitudes below traditional devices. With our demo we show that RDF/HDT can be used as a self-contained engine to retrieve RDF information in mobile devices. To date, we have explored a given set of cities and certain query templates to build the screen layout. We are now exploring a spreading activation mechanism to automatically retrieve interesting 8 In this prototype we use Nutiteq SDK Maps, available at http://www.nutiteq.com/. features of a city which are then converted to HDT on the server side. This also takes into account other datasets besides DBpedia.
This work has been funded by the European Commission under the grant PlanetData (FP7-257641) and by the Spanish Ministry of Economy and Competitiveness (TIN2013-46238-C4-2-R).