Interface with Semantic Data Storage

4.2.2 Interface with Semantic Data Storage

The user’s context information gathered and processed by the DQF is stored in a local or remote SDS. The SDS stores this information in the form of RDF triples. Depending upon the target platform different versions of the SDS are used. As specified in [GCDDSQP13], the context data is stored in a RDF triple store. GAMBAS employs two different triple stores depending upon the target platform. If the target platform is Android based then RDF‐on‐the‐go is used as a RDF triple store and if the target platform is J2SE then Apache Jena is used.

Depending upon the application requirements the context data gathered by the DQF is stored in the local or the remote SDS. In order to achieve this, SDS provides both local and remote interfaces. Both interface types allow storing Meta data, as well as the actual data. Meta data may contain properties like the time of a measurement, its lifetime, and classification with respect to privacy policies. Both the actual data and the Meta data are stored as RDF triples according to the data model developed in Task 4.1.

Both SDS interfaces manage all database operations such as addition, deletion and modification of data according to the data models. The local SDS interface for GAMBAS applications running on Android is realized as an Android service whereas for GAMBAS applications running on J2SE devices are realized as a Java service. For both types of devices, the remote interface is realized as a BASE [BASE] service.

Figure 19 – Local and Remote Components for Storing Data in SDS

In order to store data on the local and the remote storages, the DQF makes use of two components, one for storing data locally and another for storing data remotely. Both components can insert and update RDF triples in the relevant SDS. In order to store the data on either type of SDS, the context recognition applications passes the acquired context data as parameters to these components. The acquired context data passed to these components as parameters is in accordance with the semantic model for the relevant SDS storage. The data is serialized as string objects such that it can be stored as RDF triples in the appropriate triple store. As an example, the acquired context data for bus journeys may contain information such as bus id, bus location, etc, as shown in Figure 19. This data is passed as parameters to the SDS component for storage. Upon receiving this data, the SDS component signals this to the core service. The core service then manages the storage of data in the appropriate SDS. If the data is sent to the local SDS component, then the data is stored in the local SDS and if the data is sent to the remote SDS interface, then core service uses BASE for sending and storing data in the remote SDS.

4.2.2.1 Application Example

An example of sample application in which interaction between DQF and SDS is required could be a sensor data sampling application which samples sensor data such as data from audio sensor, accelerometer sensor, Wi‐Fi sensor, GPS sensor etc, and stores them either locally on the device or remotely at a server for further processing or analysis. If such an application uses the GAMBAS middleware and is required to store the data in the SDS, then the acquired sampled data by the application is passed as parameters to either the local SDS component or the remote SDS component. In either case, the sampled data passed as parameters should be in accordance with the semantic data model of the storage where it is intended to be stored. Possible fields for the sensing data to be stored may consist of sensor type, sensor reading, reading timestamp, etc. If the sensor data is to be stored on local SDS, it is first passed to the local SDS component, the data fields are serialized as string objects, converted to RDF triples and then stored in the SDS. In case the sensor data is to be stored on a remote SDS then the BASE middleware is additionally used to communicate with the remote site and the remote storage.