IUI – xQP Interface

2.3.8 IUI – xQP Interface

Design Rationale: The Intent-Aware User Interface (IUI) is based on a novel data-driven user interface which encompasses three different layers with information about a) the transport system

b) personal travel needs and behavior and c) social travel usage. In order to realize these layers, the IUI is connected to the GAMBAS middleware trough a powerful query process interface which provides access to local and remote data sources. Local data pertains to personal travel information

which includes the user’s travel history for making predictions to adapt the IUI to his future travel behavior. Remote data includes transport information hosted by third part services such as a cities’ local transport agency (e.g. estimated time of arrivals), time tables and information about the travel

habits from the user’s friends in the social network as stored on their mobile devices. Since all this data is represented based on linked data principles using RDF triples, it can be queried in a uniform

manner by means of a powerful graph-based query language irrespective of what specific kind of data is requested and where this data is located.

Interface Functionality: All transport related information will be provided by an external service provider. The IUI is heavily dependent on transport data, but it does not establish a direct connection to 3 rd party services. Instead it benefits from xQP interfaces to access SDS and read the data. Therefore IUI will use an interface from xQP to connect to external services and read transport related information and other information objects, which has been described previously. In particular, this interface is a façade from xQP that calls methods and translate the received data into an understandable format for IUI. As a result, the interface consists of a single power query processor which allows us the IUI to specify generic queries over data stored on local and remote SDS:

 Select (SPARQL Query)  result set :: Local & Remote: Enables the retrieval of bindings for requested variables. To specify the variables as well as conditions that bindings for them

must match, a SPARQL select query can be given. A query can be executed on a single data source or multiple ones, allowing to query and integrate information from multiple users at once. Matching data items are returned as a result set, containing all suitable bindings for each specified variable.

Foreseen Usage: The result of xQP query contains dynamic information objects from the target transport network, which is provided by a 3 rd party, hosted in SDS and wrapped through xQP. These information objects include qualitative attributes of transport i.e. estimated time of arrival(s) for the given station (ETA), crowd level for the given station and/or between stations in a bus.

There is another category of information which is semi-static information. They include time tables for each bus line, routing points of bus lines and stations coordinates. Static information objects could be read once from xQP and thus there is no need for frequent fetch (unlike dynamic one which requires frequent fetch).

It is important to note that dynamic information should be provided in real time, for instance when the user checks the ETA, she should receive it in real time. This means that there is a need for a query response time threshold. Otherwise the received data is getting obsolete for the IUI (which is presented to the end-user).

Possible Optimizations: Frequent data access may be a critical factor for the IUI, especially when the queries need to be forwarded to remote data storage over cellular network connections. The low bandwidth of these connections and high variance in quality of service may slow down the query process and cause significant delays in information delivery that can negatively affect the user’s experience. In order to improve upon this, the design of IUI foresees a caching strategy, where static data(routing information, bus coordinates and time tables info.) is kept on the mobile device so that no repeated updates are required. This is especially useful for transport network data, which is not expected to change very often. For dynamic data (ETA and crowd level), possible optimizations strategies include prefetching strategies, where the data is retrieved before it is requested by the user. As the data is already available on the device prior to the access to the information, the delay experienced by the user can be minimized.