Context-based mobile GeoBI: enhancing business analysis with contextual metrics/statistics and context-based reasoning di Diallo, Badard, Hubert, Daniel Sistemi di Elaborazione dell'informazione Prof: Eliseo Clementini Studente: Marco Taraborrelli
Outline 1. Introduction 2. Realistic scenarios of context-based reasoning and contextual business analysis 3. Enriching contextual information with GeoBI contextual metrics 4. Architecture for delivering and binding GeoBI contextual metrics with business performance metrics 5. Persisting the metrics/statistics augmented mobile GeoBI context ontology 6. Discussion and Conclusions
Keywords Business Intelligence GeoBI Mobile Geospatial Business Intelligence Context-based Reasoning Contextual metrics/statistics Business Performance DSS Decision Support System SOA - Service Oriented Architecture Data Warehouse OWL Ontology Web Language
Introduction Thanks to mobile computing, professionals are accessing their organizations data from anywhere at any time by using mobile devices. This requires these mobile business people to be supported with suitable mobile decision support systems (DSS), especially mobile BI ones. That such suitable mobile DSS should be GeoBI-enabled, to integrate geospatial dimensions of business and mobility, and context-based, to capture the user s mobile context.
Introduction(2) Initially was proposed a UMLbased multilevel mobile GeoBI context model supporting context-sharing and structuring. For the purpose of GeoBI context-based reasoning, the model was extended and detailed to provide an OWLbased ontology model, since OWL is more suitable for knowledge sharing and context reasoning than UML.
Introduction(3) In this study, we highlight, through realistic scenarios: the requirement for context-based reasoning to enhance mobile GeoBI experience the need for contextual metrics/statistics to help mobile business professionals discover their local context capabilities and opportunities the need for crossing business performance metrics with contextual metrics to help mobile professionals in discovering the context hidden behind business performance figures
2. Realistic scenarios of context-based reasoning and contextual business analysis
General context of scenarios: BioWYNX mobile selling activities M. Rossi, has been moved from Washington DC to Quebec City as mobile sales analyst and strategist to reorganize and expand the local branch of BioWYNX. BioWYNX is a multinational firm specialized in selling biological foods. To minimize delivery fees, BioWYNX disposes of at least one storehouse per district from which salesmen can supply customers and where customers can also go and purchase directly. Its customers are mostly individuals, but also organizations. Customers may be classified according to their age group (e.g. 18 25 years old), social group (e.g. students vs. workers vs. managers, etc.) or organizations there are affiliated to.
General context of scenarios: BioWYNX mobile selling activities(2) The figures represents the snowflake schema of the data warehouse from which OLAP cubes and minicubes are pre-calculated and generated to ease and fasten mobile analysis.
Need for contextual metrics/statistics In that location (AOI), who are the supervisors of Steve that cumulated more than $100.000 sales of chocolate family products last month, and that have their offices near to BioRoom hotel, or near to my current position? -the ratio Man/Woman of the population -the rate of unemployment -the most consumed foods These kinds of metrics are mostly available as raw documents, e.g.: hardcopy reports, static web pages, downloadable files, etc. Therefore, M. Rossi, for a cross analysis should have to: bring with him tons of statistics paper reports and perform long and time-consuming exploration and searches on statistics websites.
Need for contextual metrics/statistics(2) Given the high need for such statistics in decision making, BI/GeoBI systems should be enriched with these ones. a) Integrating contextual metrics into the same OLAP cubes as business performance metrics b) Putting contextual metrics into separate OLAP cubes as contextual metrics data cubes c) Integrating contextual metrics/statistics into an inferable GeoBI context model (e.g. OWL-based GeoBI context ontology)
Need for crossing business performance metrics with GeoBI contextual metrics Let us now consider that M. Rossi would like to deeply analyze the business performance figures his predecessor left. Since the values of some business metrics appear to be inexplicable, M.Rossi would like to analyze the GeoBI context in which those figures were recorded: e.g. how were business, social, environmental contexts?
3. Enriching contextual information with GeoBI contextual metrics
Defining contextual metrics We define a contextual metric as a location-based and time-dependent statistical calculation or measurement providing contextualized description about persons (e.g. birthrate within Canadian people in 2010), objects/products or events/activities (average number of social events each weekend in Beauport) localized in the surrounding context of an organization/person.
Extending and enriching mobile GeoBI context with contextual metrics
Architecture for delivering and binding GeoBI contextual metrics with business performance metrics
Web services composition strategies Services are interoperable (platform and network independent) and loosely-coupled software units/routines that client applications or other services can discover and invoke to achieve over a network, a given task. They can be deployed over internet as web services by using languages and protocols depending on the selected architectural approach. Two approaches exist: REST-oriented and SOAP-oriented. In addition to being RESTful or SOAP-based, a service can be atomic or composite/complex. Atomic services perform simple tasks/functionalities such as retrieving data from the database. To achieve complex functionalities, atomic services can be combined and conveniently arranged to build composite services.
Web services composition strategies(2) SOAP (Simple Object Access Protocol) approach is a message-oriented paradigm where client applications and web services communicate via asynchronous messages which encapsulate remote operations and data into XML format. A Web Services Description Language (WSDL) is used to describe web services communication interfaces (e.g. url, port), methods/operations, data types, etc.; while a UDDI (Universal Description, Discovery and Integration) registry is used to expose and help discover services. SOAP, WSDL and UDDI are W3C well known standards. REST (Representational State Transfer) approach is a resource-oriented paradigm where client applications access web services through URIs by calling HTTP methods (e.g. GET, POST) to interact with operations and resources provided by these services. Unlike SOAP services, there is not yet a standardized language for describing RESTful services.
Web services composition strategies(3) BPEL (Business Process Execution Language) acts as the de-facto standard for composing services. It defines a composite service as a process invoking (synchronously/asynchronously) services through their WSDL description, into a given (sequential/parallel) sequence. This raises a problem regarding the use of BPEL to orchestrate RESTful services which do not use WSDL. Main solutions to overcome that problem are: 1. WSDL bindings for HTTP: mapping WSDL operations to URIs, HTTP methods, and operations exposed by RESTful services 2. REST adapters: hiding the heterogeneity by using an adapter service that translates and forwards BPEL calls to RESTful services and vice-versa through WSDL schemas 3. BPEL extensions for REST: extending BPEL to enable a direct support of RESTful services We have chosen BPEL with HTTP bindings since this option is widely tested and adopted by open source orchestration engines like Apache ODE.
Mechanisms of delivering data to mobile users Three main classes of delivery strategies can be combined: (i) push or pull approaches supplied through (ii) periodic (e.g. scheduled) or a-periodic (e.g. event-driven) requests by using (iii) one-to-one (unicast) or one-to-many (multicast) delivery system. Publish-subscribe and users request-response are default push and pull techniques we adopt for the future implementation of the proposed architecture. The push mode will be implemented by using one of most popular push technologies available for smartphones: (i) Apple Push Notification Service (APNS) (ii) Android Cloud to Device Messaging Framework (C2DM) (iii) Microsoft Push Notification Service (MPNS)
Description of the architecture The GeoBI-SOA is composed of: 1. The context-aware service (CawS), responsible for acquiring the user s context and handling push/pull requests 2. Context ontology databases: since contextual information and contextual metrics might evolve differently we have chosen to separate them into two models stored into two different ontology databases referring each other 3. The GeoBI Services Manager (GeoBI-SM), responsible for selecting the requested context-based GeoBI service among available ones 4. Rules-based and context-based reasoning engines, responsible for loading and inferring on contextual information and metrics (and rules) to find contextual metrics matching the submitted request
Description of the architecture(2) 5. The Mobile Output Presentation Service (MOPS), responsible for delivering GeoBI data to mobile clients 6. External GeoBI services exposed by GeoBI infrastructures implanting the snowflake data warehouse schema presented before 7. External Mapping and location-based services for processing and representing geospatial features The proposed architecture operates as follows in push and pull modes.
Description of the architecture(3)
The GeoBI SOA in pull mode The proposed architecture operates as follows: 1A. The user requests contextual metrics (click on a command button) 2A. RHS handles the request and calls CAS to capture the up-to-date mobile GeoBI context, including the user s task context from which the request was performed 3A. CAS communicates with the mobile GeoBI application and gathers contextual information including contextual dimensional parameters regarding the business performance metric/measure, M. Reason was consulting (e.g. location: Beauport, Time: Dec. 2011, ProductCateg: Chocolate, metric/measure: Amount of sales, value:4000$) 2. CAS updates the contextual information database with recently gathered contextual information
The GeoBI SOA in pull mode(2) 3. RHS calls GeoBI-SM with the request and the GeoBI context including the request context. GeoBI-SM launches MBS which may need to call (β) OpenLS location-based services to get expected geospatial features (e.g. location name) or (λ) GeoBI services to get additional metadata regarding the business metric/measure M. Reason was consulting 4. MBS submits the request to reasoning engines 5. Reasoning engines load contextual information and metrics and infer to find contextual metrics matching the submitted request 6. The reasoning result (e.g. contextual metrics regarding chocolate products in Beauport District) are sent back to MBS 7. MBS (or CMDS) communicates the results to ORS in MOPS for rendering purpose 8. After conveniently rendering the contextual metrics, ODS in MOPS sends the output to the mobile application for display
6. Persisting the metrics/statistics augmented mobile GeoBI context ontology
Persisting the metrics/statistics augmented mobile GeoBI context ontology Unlike common organized data, there is no particular data model to build to get RDF/OWL data stored into a database. These are stored in the form of triple stores into a predefined data model for optimized storage and retrieval of RDF triples (subject, property, object). Many javabased frameworks like Apache Jena, Sesame implement persistent ontological data that way into relational databases like MySQL, PostgreSQL, SQL server, Oracle, etc. The figure exposes how we used Jena Java-based framework to connect to a PostgreSQL database (mcgeobi_ont_db_metrics), read our ontology model from an OWL file, and write it into mcgeobi_ont_db_metrics.
7. Discussion and Conclusions
Discussion Through realistic scenarios, the paper has highlighted the need for additional features to improve decision making, amongst: 1. The requirement for context-reasoning to enhance mobile GeoBI activities 2. The need for GeoBI contextual metrics/statistics to help mobile business professionals discover their local context capabilities and opportunities 3. The need for crossing business performance metrics with GeoBI contextual metrics to help mobile business professionals discover the context hidden behind business metrics and KPIs
Conclusions To fulfill these requirements, we have proposed: 1. A definition of contextual metrics/statistics 2. A characterization and organization of contextual metrics into contextual metrics dimensions 3. An enrichment of previous OWL-based mobile GeoBI context model with contextual metrics to provide mobile professionals with a richer business analysis support 4. A context-based GeoBI service-oriented architecture for delivering contextual metrics and crossing them with business metrics. Some challenges regarding service composition approaches and mechanisms of pushing/pulling data to mobile users were discussed Future work will deal with completing the prototype development while further work will be dedicated to providing an integrated context-based and semantic-augmented mobile GeoBI solution