The paper describes a lightweight general purpose RDF framework for Android. It allows to deal uniformly with RDF, whether it comes from the web or from applications inside the device. It extends the Android content provider framework and introduces a transparent URI dereferencing scheme allowing for exposing device content as linked data.
Smartphones are becoming the main personal information repositories. Unfortunately, this information is stored in independent silos managed by applications and thus, it is difficult to share data across them. Nowadays, mobile operating systems, such as Android, deliver solutions in order to overcome this, but they are limited by the application database schemas that must be known beforehand.
The difficulty to share phone data at the web scale can be seen as another drawback. One can synchronize application data, such as the contacts or the agenda using a Google account. However, they are not generic solutions and there it is no mean to give access to data straight from the phone.
Our goal is to provide applications with a generic layer for data delivery in RDF. Using this solution, applications can exploit device information in an uniform way without knowing from the beginning application schemas. This information can also be exposed to the web and web information can be considered in the same uniform manner. Moreover, we propose to do it along the linked data principles (provide RDF, describe in ontologies, use URIs, links to other sources).
For example, in the future, this application could be used as a personal assistant. When one would like to know which of his contacts will participate to a scientific conference, he can query the calendar of all his contacts in order to retrieve the answer. For sure, according to the security settings of the corresponding contact, he may be allowed or not to access the calendar.
The mobile device information can as well be accessed remotely, from any web browser, by any persons who has granted the access to it. In this case, acts like a web server.
We presented a first version of the RDF content provider in [
We first describe the context in which the Android Platform stores its data, and how it can be extended in order to integrate RDF. Then, we present two applications that sustain its feasibility: the first one is an RDF browser that acts like a linked data client and allows the navigation through the device information, and the second one is an RDF server which exposes its information to the outside world. We continue to present the challenges raised by such applications and solutions we implemented for them. Finally, we conclude presenting future improvements and challenges in this field. 2
Inside the Android system, each application runs in isolation from other applications. This Linux-based operating system assigns to each application a different and unique user. Only this user is granted access to the application files. This allows one to take advantage of a secure environment, but prevents the exchange of data across applications. To overcome this drawback, Android provides the content provider mechanism.
Content providers enable the transfer of structured data between device
applications. They encapsulate the data and control the access to it through an interface. This
interface empowers one to query the data or to modify it ([
A content provider is a subclass of ContentProvider and implements the following interface: Cursor query( Uri id, String[] proj, String select, String[] selectArgs, String orderBy ) Uri insert( Uri id, ContentValues colValueList) int update( Uri id, ContentValues colValueList, String select, String[] selectArgs ) int delete( Uri id, String select, String[] selectArgs ) String getType( Uri id ) .
With the content provider API, each data (table or individual) is identified by a URI having the following structure: content://authority/path/to/data The content: scheme is the cornerstone of each Content Provider URI, the authority identifies the provider, i.e., the dataset, and the path/to/data identifies a particular table or individual (row) in the dataset. For example, the URI content://contacts/people refers to all the people in the contact application, and the URI content://contacts/people/33 identifies a specific instance of these, namely the instance having the id 33.
When an application wants to access a particular piece of data, it queries its URI. This is done through a call to the ContentResolver which is able to route the query to the right content provider.
From a semantic web point of view, using URIs to identify data is a strong point of the Android content providers. Still, there are several limitations if we would like to use them as a linked data interface.
Specifically, URIs used by content providers are local to each device, i.e., not dereferenceable on the web, and not unique. The content scheme used by providers is not a standard protocol. Furthermore, two distinct devices will use the same URI to identify different data. For example, by using content://contacts/people one would be able to access the contacts from both devices.
Another drawback is the SQL interface of the Android content providers. The queries are issued in an SQL manner and the results are presented to the user as a table. 3
We designed the RDFContentProvider framework to give a semantic web flavour to Android and to overcome these problems. It is composed of the RDFProvider API and the RDFContentResolver application. The API must be included inside the applications that want to access RDF providers and inside the applications that want to define new RDF content providers. The RDFContentResolver application is the one that records all the RDF content providers installed on the device and routes queries to the relevant provider. Figure 1 gives an overview of the framework architecture.
RDFHttpContentProvider RDFPhoneSensorsContentProvider
RDFBrowser uri uri uri rdf rdf
uri RDFContentResolver
u rdf ri r d f uri – RdfContentProviderWrapper: A subclass of RdfContentProvider which allows for adding RDF content provider capabilities to an existing classical content provider.
RDFContentProvider follows primarily the same kind of interface as ContentProvider. The minimal interface to implement linked data applications is: – RDFCursor getRdf( Uri id ) The Cursor iterates on a table of subject-object-predicate (or object-predicate) which are the triples involving the object given as a URI. If one wants to offer a more elaborate semantic web interface, i.e., a minimal SPARQL endpoint, the following methods have to be also implemented: – Uri[] getTypes( Uri id ): returns the RDF types of a local URI; – Uri[] getOntologies(): ontologies used by the provider; – Uri[] getQueryEntities(): classes and relation that the provider can deliver; – Cursor query( SparqlQuery query ): returns results tuple; – Cursor getQueries(): triple patterns that the provider can answer. The RDF providers that we have developed so far are implementing only the first three primitives. 3.2
The RDFContentResolver service has the same goal as the ContentResolver belonging to the Android framework. It maintains the list of all the installed RDF content providers, and forwards the queries it receives to the corresponding one. This application is never visible to the user, therefore we have implemented it as an Android service.
When an RDF Content Provider is instantiated by the system, this provider automatically registers to the RDFContentResolver. A principle similar to the one from the Android Content Provider framework is used.
The RDFContentResolver can route both the local (content:) and external (http:) URI-based queries. In case of a local URI, i.e., starting with the content scheme, the resolver decides to which provider it must redirect the query. In case of an external URI, i.e., starting with the http scheme, the provider automatically routes the query to the RDFHttpContentProvider (see Figure 1).
The RDFHttpContentProvider allows one to retrieve RDF data from the Web. It parses RDF documents and presents them as RDFCursors. So far, only the minimal interface has been implemented, i.e., the getRdf( Uri id ) method. 3.3
The RDF Content Resolver application is also bundled with several RDF content providers encapsulating the access to Android predefined providers. The Android framework has applications that can manage the address book and the agenda. These two applications store their data inside their own content provider.
In order to expose this data as RDF, we developed the RDFContactProvider and the RDFCalendarProvider. These providers are wrapper classes for the ContactProvider and the CalendarProvider residing inside the Android framework.
RDFContactProvider exposes contact data using the FOAF ontology. It provides data about a person’s name (display name, given name, family name), about its phone number, email address, instant messenger identifiers, homepage and notes.
RDFCalendarProvider provides access to the Android calendar using the RDF Calendar ontology1. The data supplied by this provider contains information about events, their location, their date (starting date, ending date, duration, and event time zone), the organizer of the event and a short description.
RDFPhoneSensorsContentProvider aims to expose sensor data from the sensors embedded inside the mobile device. Contrary to the others, they are not offered as Content Providers. At the present time, it only delivers the geographical position (retrieved using the Android LocationManager service). In order to express this information in RDF, we use the geo location vocabulary2, the one that provides a namespace for representing lat(itude) and long(itude). 4
The RDF Browser acts like a linked data client. Given a URI, the browser makes an HTTP URI request in order to retrieve the information from the specified location. If the data contains other URIs, the user can click on them and the browser will issue a new query with this URI.
An example can be found in Figure 2. In this case, the user uses the RDFBrowser to get the information about the contact having the id 4. When the browser receives the request, it sends it further to the RDFContentResolver. Since the URI starts with the content:// scheme and has the com.android.contacts authority, the resolver routes the query to the RDFContactProvider. This provider retrieves the set of triples describing the contact and sends it to the calling application which displays it to the user. Thereupon, the user decides that he wants to continue browsing and selects the contact’s homepage. In this case, since the URI starts with the http:// scheme, the resolver routes the query to the RDFHttpContentProvider. The same process repeats and the user can see the remote requested file, i.e., Tim Berners-Lee FOAF file. 5
The RDF Server is a new component added to the architecture. This server provides to the outside world the data stored into the device as RDF. Due to the fact that the server must maintain a permanent connection to the Internet without user interaction, we implemented it as an Android service, i.e., a background process.
One important issue appears when one would like to get data from a device because the URI used to query the content providers has a local meaning. In the outside world, 1 RDF Calendar vocabulary: http://www.w3.org/TR/rdfcal/. 2 Geo location vocabulary: http://www.w3.org/2003/01/geo/ . the URI used to query the address book of two different persons will be the same, but the content of the address book will be different.
The server principles are quite simple. In the beginning, the server receives a request from the outside. Then, it dereferences the requested URI, i.e., it translates the external URI into an internal one, which has meaning inside the Android platform. The RDF Server sends it further to the RDFContentResolver. In a manner similar to the one explained for the RDF Browser the set of triples is obtained but, before sending this set to the server, the URIs of the triples are externalized and the graph is serialized using a port of Jena under the Android platform.
The URI externalization process translates the local URI content://authority/path/to/data into the dereferenceable one http://deviceIPAddress:port/authority/path/to/data. Reversing the translation of such a URI is possible since both the authority and the path are kept during the externalization process.
Usually, mobile devices do not have a permanent IP address and thus, the externalized URIs are not stable. To overcome this, a dynamic DNS client34 can be used.
In addition, the server supports a minimal content negotiation mechanism. If one wants to receive the data in RDF/XML, it will set the MIME types of the Accept-type header of its request to "application/rdf+xml" or to "application/*". In the opposite case or when the client sets the MIME type to "text/plain", the data will be transmitted in an N-TRIPLE format. Not only the requester has the opportunity to express its preferences regarding the format of the received data, but the default format of the transmitted data can be specified in the server settings, as well the port on which the server can listen on and the domain name server for it. 3 Dynamic DNS Client: https://market.android.com/details?id=org.l6n.
dyndns&hl=en. 4 DynDNS: http://dyn.com/dns/ .
Fig. 3. RDF Server response.
An example can be found in Figure 3. In this scenario, the user retrieves information about the fourth contact from the device address book. The request is processed by the RDF Server in a manner similar to the one of the RDF Browser. 6
The RDF Server included in our architecture eases the access of the user to the RDF
data found on the web. For that purpose, we wanted to reuse an existing semantic web
framework, such as Jena or Sesame. Yet they are not suitable to be employed under
the Android platform (the code depends on some libraries that are unavailable under
Android). There are a few ports of these frameworks to Android: Microjena5 and
Androjena6 are ports of Jena and there exists a port of Sesame to the Android platform
mentioned in [
A problem that arises when we use this framework is that the size of the application increases substantially. This problem could have been avoided by reimplementing only the Jena modules that are needed in our architecture. Still, we would like to improve our architecture by adding more features (such as a SPARQL query engine) that require additional modules to those used to read/parse/write RDF, available in Jena.
A tool that we found useful in our development process was ProGuard. ProGuard7 is a code shrinker, optimizer, and obfuscator. It removes the unused classes, methods or variables, performs some byte-code optimizations and obfuscates the code. The tool proved to be efficient in reducing the size of our application (our framework including Androjena) by half, i.e., its initial size was 6.48MB, and after we applied the tool it diminished up to 2.98MB.
The existence of such tools as ProGuard, is a step forward in the continuous battle between applications that require a considerable amount of space for storing their code and devices with a reduced memory storage.
We are currently examining how to query the device data using SPARQL. There are
two main ways of doing this:
5 http://poseidon.ws.dei.polimi.it/ca/?page_id=59.
6 http://code.google.com/p/androjena/.
7 http://proguard.sourceforge.net/.
– creating a new RDF content provider which relies on a triple store to deposit the
data [
At the moment, we are investigating the second option. There are several available tools that can make the translation from SPARQL to SQL, like Virtuoso or D2RQ. However, these tools solve only half of the problem because the SQL queries have to be adapted to the ContentProvider interface, i.e., the queries have a particular format, different than the SQL one. This interface allows for querying only one view of a specified table at a time, hence it is not possible to ask Content Providers to perform joins.
Further challenges regarding security must be taken into account. The user of the application should be able to grant or to deny the access to its personal data. A specific vocabulary should be used in order to achieve this 8. More that that, the dangers of granting system access to a third-party user can be avoided by using a secure authentication protocol 9.
As can be seen, there are still technical problems in implementing a full RDF framework at the core of Android. Specific solutions must be developed.
Involving Android devices in the semantic web, both as consumers and providers of data, is an interesting challenge. As mentioned, it faces the issues of size of applications and URI dereferencing in mobility situations.
A next step is to provide a more fine grained and structured access to data through SPARQL querying. This promises to raise the issue of computation, and thus energy, cost on mobile platform.
A further issue will be the control of privacy in such a framework. But here too, we think that semantic technologies can help.