In the today’s mobile, global, highly competitive, and technology-based business, mobile professionals deserve to get supported with suitable mobile Decision Support Systems (DSS) that we believe, should be 1) GeoBI (Geospatial Business Intelligence)-enabled to take into account geospatial features, and 2) context-based to capture the mobile user’s reality. According to [1] , about 80% of businesses’ data has a geo-spatial dimension. Thereby, GeoBI realizes an intelligent coupling of GIS tools with Business Intelligence (BI) technologies to suitably exploit, analyse and visualize geo-spatial part of business data (e.g. borders, places, addresses, GPS coordinates, routes, etc.). Moreover, since professional mobility is usually justified by the mobile worker’s need to experiment a physical proximity [2] to resources, in order, among other things, to acquire accurate information from what he sees, hears, or senses within his work context, a mobile GeoBI system should help capture, organize and structure contextual information into an appropriate context model that would be exploited with BI data to deliver context-based analytics.

Modelling mobile contexts is still a research issue [3] [4] , especially mobile GeoBI contexts, since there is not yet either a model or a relevant taxonomy regarding GeoBI contextual information [5] . To fill this gap, the latter authors proposed “a multilevel mobile GeoBI context”. Figure 1 presents that model built upon three hierarchical levels: 1) the context-sharing level enables interaction and information sharing between local and remote contexts; 2) the mobile GeoBI context levels organize context into three hierarchical levels, which fits with human perception of space: personal, ambient and surrounding contexts. Ambient context is a subset of surrounding context and both are composite of GeoBI context and subclasses of “context around the user” as shown in Figure 1; 3) the context dimensions structures contextual information into relevant dimensions for BI and mobility: personal, business, spatial, social, technological and environmental contexts. The geospatial (H, ε) and temporal (ξ) pictograms highlight that a mobile GeoBI context is location-based and time-dependent. The model was designed into UML (Unified Modeling Language) to conveniently structure contextual information and was limited to top-level concepts to handle basic challenges regarding context modeling.

In this paper, we propose to extend and detail that top-level UML-based model into an OWL (Web Ontology Language)-based context ontology to provide context-aware applications and users with more specific and precise contextual information and context-based reasoning capabilities.

Context reasoning allows applications to infer and discover new contextual information from initial facts. For instance, given that location A (e.g. XYT museum) is located in B (e.g. District 0911) which is located in C (e.g. WYNX sales Zone), if a mobile device is located at XYT museum, then it can derive that the salesman (e.g. Steve) using the device is located in WYNX sales zone. To enable such reasoning, an inferable GeoBI context model is required. In the literature, OWL is usually used to build inferable ontologies [6] and is recognized as more suitable to support knowledge sharing and context reasoning than ER (Entity/relation) and UML [7] . Ontology defines, describes and represents an area of knowledge for the purpose of knowledge-sharing, inferential logic and reasoning [6] . OWL is a text-based language that extends RDF (Resource Description Framework) and RDF-Schema with richer semantics and provides extensibility and compatibility with web standards [8] . To ease its understanding and improve its readability, an OWL-compatible graphical formalism is provided by Cmap Tools COE [9] . This one will be extended with geospatial and temporal pictograms to conveniently describe spatio-temporal concepts and will be then used to design the proposed OWL-based mobile GeoBI context ontology.

The paper is organised as follows: Section 2 highlights the need for GeoBI context-based reasoning and OWL modeling, and presents CmapTools. Section 3 translates the UML-based context model into an OWL-based top-level GeoBI context ontology. Section 4 extends that ontology by detailing each of its context dimensions. Context quality issues are handled in Section 5 and implementation architecture is provided in Section 6.

For the purpose of enabling context reasoning, the top-level UML-based context model (Figure 1) has been translated into OWL-based GeoBI context ontology (Figure 5). Note that colors (red, blue) are used by CmapTools to highlight some categories of links, and sometimes by us (other colors) to differentiate intersecting links. They do not carry a particular meaning.

That top-level context ontology provides a generic overview of a mobile GeoBI context stakeholders, highlights its hierarchical multilevel structure, and defines it as a union of (i.e. “any of”) three hierarchical context levels (personal, ambient, and surrounding contexts) which are in turn defined as combinations of context dimensions.

The union relation is more explicit in the OWL excerpt provided in Figure 4. The context dimensions were selected by [5] based on their relevance for mobility and BI activities (See Table 2) and were dispatched into the three hierarchical context levels to match with the human mental representation of space identified by [17] : 1)

the body space, 2) the space around the body, and 3) the navigation space. The personal context is about information regarding the user such as his profiles, goals, tasks, etc. The ambient context is about the immediate environment around the user in which things can be more accurately sensed by the user, while the surrounding context potentially covers the whole surrounding environment. The ambient context is a subset of the surround- ing context. Their difference resides in their scope. Indeed, ambient context is a restriction of surrounding context to a given area of Interest (AOI), which leads to a kind of projection (limitation) of the dimensions content inside this AOI. Conversely, a surrounding context is somehow, an extension of ambient context to a wider AOI. Both have the same context dimensions.

As nobody is completely cut off from the world, especially in nowadays global business world, this context ontology provides a suitable way to tackle the issue of context-sharing, i.e. the fact that a local business contextual information (e.g. gas price in Quebec City) may be affected by a remote context whatever the business context (e.g. wall street stock exchange) or any other context (e.g. war in Libya) is. This is expressed in the proposed ontology (Figure 4, Figure 5) by the relations connecting local and remote contexts through the shared contextual information, and is exemplified by the following individuals: 1) “Gas business in Quebec city” which is an instance of “Local Context”; 2) “War in Libya” which is an instance of “Remote Context”; 3) “Daily oil production down” which is an example of “contextual info” shared by the remote context and that may influence the local context. In the figure, the couple of relations shares 1/influences 1 and shares 2/influences 2 exposes the fact that a remote context may share (share 1) a contextual information that influences (influences 1) the local context, and conversely, the local context may may share (share 1) a contextual information that influences (influences 1) a remote context. To describe the spatial coverage/attribute of an object instance (e.g. gas Business in Quebec City) the has Geom relation is used to list its geometric coordinates in Geo-OWL format.

Details composing personal, business, technological, spatial, social, and environmental contexts are inventoried and designed into detailed ontologies in Section 4.

Besides top-level concepts, more specific concepts are required to enable mobile GeoBI applications sense or retrieve detailed contextual information (e.g. user position, his office address). This section provides for each context dimension (personal, business, technological, spatial, social, and environmental contexts), a detailed context ontology.

Contextual information identified in the different context ontologies afore proposed can be collected in real-time, from physical sensors sensing physical world (e.g. location, motion), and logical sensors sensing IT activity (e.g. detecting the user’s location from his IP address). But some contextual information may require a manual input (e.g. the user’s personality traits, etc.). This means that at a given instant t, not all contextual information is acquired and fed in the context ontology: there could be missing one. Moreover, it might be unknown, ambiguous, imprecise or erroneous [51] . So, context-aware mobile applications exploiting GeoBI context ontologies must be able to deal with incomplete and uncertain contextual data.

Context uncertainty modelling and reasoning are still important research issues [52] - [54] , that cannot be completely covered in our current research thesis whose focus regarding context is mainly identifying and modeling contextual information that is relevant for mobile Business Intelligence. Issues regarding data security, data confidence and data certainty, etc., will be addressed in further work.

However, in our current model, context uncertainty is already handled at two levels of quality control: 1) by defining quality parameters and metrics for sensors [55] and/or 2) by associating/annotating contextual entities with Quality of Context metrics [54] such as certainty level [51] . The first level is defined in the technological context ontology (Figure 10) by modeling quality properties for sensors (devices or software) used to capture the information. Hence, to the GPS sensor installed on the mobile used by salesman Steve, could be attached quality metrics regarding its precision (e.g. 20 m) and accuracy (e.g. 70%) parameters in measuring the user’s current position. Then, the accuracy and precision of the captured value can be derived from the GPS device quality parameters. The second level of quality control consists of annotating contextual entities with Quality of Context metrics QoC [54] , by indicating for example their level of certainty. For example, the user’s position previously captured might be corrected based on the GPS precision and stored as being 90% sure, whereas a user profile information input (e.g. work experience) might be moderated by administrators and set as doubtful (e.g. 0.3). The certainty value might be an estimation or a probability [52] [56] . This second level is not explicitly modeled because of readability issue, but thanks to OWL dynamic capability for creating additional properties, a certainty label and value can be created at runtime. Unknown or missing information is considered as null and the user may be requested to enter it if required. For each contextual information, its data type is annotated to allow reasoning engines make the difference between text, numeric, and geospatial, etc. values.

Context uncertainty also includes geospatial and temporal dimensions of contextual information. Thanks to our integration of these spatial and temporal dimensions in our model, this issue is half solved, at least regarding data freshness and location resolution since we can know the validity time of a contextual information (begin and end time) and its precise location thanks to its geographic coordinates (in a given) our model retrieves as geometric object for geospatial features. However, this can be enforced by the use of QoC metrics such as timescale units (e.g. seconds, hours, months, years), location resolution (e.g. district level, city level, state level, etc.).

Further enchancement could be brought to our current solution of handling context uncertainty based on QoC annotation [54] , by considering the use of:

・ fuzzy logic [57] ;

・ probabilistic logic [56] ;

・ Markov models [58] ;

・ Bayesian networks [59] ;

・ Dempster-Shafer theory [60] .

For the purpose of implementing such context-aware delivery service of contextual metrics, we propose (Figure 14), a service oriented architecture (SOA) for GeoBI location-based and context-based reasoning and analysis. Service oriented architectures ease abstraction, reusability and interoperability, and are more suitable for mobile computing than client/server architectures [61] . The proposed architecture operates as follows:

The context-aware service is responsible for handling “push” and “pull” requests. It regularly senses and acquires contextual information from the user’s mobile context through various sensors (e.g. GPS, Gyroscop, log-

ical sensors, etc.) available on the mobile device on which a context-aware mobile GeoBI application is running.

“Pull” requests are issued by the mobile user, while “push” requests are auto-generated by the context-aware service based on preconfigured indications (e.g. when a salesman enters a new location?e.g. district?, send him the list of top 5 best-selling products in that location). As a case study, let consider that salesman Steve wants to get the sales performed by the supervisors of the best performing salesman (e.g. John) of this quarter in the sales zone he is located in (see Section 2.1).

1) Once Steve submits his request, the mobile application captures his current context (e.g. location, agenda, etc.) and sends the request and the captured contextual information to the context-aware service (1A). The context-aware service handles these and may call back the mobile application (1B) to get additional contextual information if necessary (e.g. if the submitted request for enriched HD BI graphics that require the mobile device battery level to be greater than 10%, the battery current level has to be retrieved).

2) The contextual information database is updated with acquired information to keep contextual information up-to-date. The GeoBI context ontology database is supposed to be fed with facts.

3) The context-aware service calls the GeoBI Services Manager (GeoBI-SM) by indicating the GeoBI service requested by the user, and by transmitting the request and captured contextual information. GeoBI-SM launches the requested service (e.g. GeoBI sales delivery service) which builds an ontological request?e.g. by using SPARQL [62] ?to retrieve or derive from the GeoBI context ontology, all contextual data (e.g. current sales zone, all supervisors of John) required to select the requested sales. A BPEL (Business Process Execution Language) process can be used to orchestrate and indicate how and when the services should be called [63] [64] .

4) GeoBI-SM submits the request to the context-based reasoning engines.

5A) and 5B) Reasoning engines?e.g. Jena [65] ?load the GeoBI context ontology and facts into their knowledge bases, and then infer to get the requested data. The reasoning process may be enriched with semantic rules?e.g. SWRL [66] rules?that can be written by semantic data specialists to into take account business rules (e.g. the relation of owning a company is transitive). These rules might also indicate the minimum threshold of certainty level defined by the company (e.g. 0.6) from which a given contextual information can be accepted as valid.

6) The reasoning results (e.g. Steve’s current sales zone from his current position, all supervisors of John) are sent back to GeoBI-SM.

7) GeoBI-SM operates a context-based request of GeoBI data (e.g. sales) from GeoBI infrastructures by using contextual information returned by reasoning engines as parameters (e.g. select sales performed by the list of supervisors within the current sales zone).

8) Location-based services and mapping services may be called by the GeoBI-SM to display maps and locations (e.g. display in background, places where sales were performed).

9) GeoBI-SM communicates output data to the Mobile Output Presentation service which renders and sends it to the mobile GeoBI application in response to the user’s push/pull request.

A prototype is currently under development and will be published in future papers.

This paper has supplied an extended and detailed OWL-based mobile GeoBI context ontology to provide context-aware applications and users with relevant contextual information and context-based reasoning capabilities. Throughout the article, we have successively: 1) highlighted the inferential power of OWL ontologies and the need for GeoBI context-based reasoning and OWL modeling; 2) presented and integrated spatial and temporal pictograms and properties into Cmap Tools and OWL to suitably design spatio-temporal concepts; 3) proposed a multilevel top-level mobile GeoBI context ontology which provides a generic overview of context stakeholders and highlights its hierarchical multilevel structure which matches with human cognition and contextual information aggregation; 4) provided for each context dimension (personal, business, technological, spatial, social, and environmental contexts) a detailed context ontology; 5) tackled context acquisition and quality issues; and finally, 6) proposed an implementation architecture.

Based on this work, further work is dealing with the development of a functioning prototype. Future works will introduce the notion of contextual metrics (e.g. revenue per capita) besides contextual information, and deal with integrating them into the OWL-based mobile GeoBI context ontology proposed in this paper in order to boost its capacity to support context-reasoning and contextual business analysis.