Towards a Universal Notification System Snehasis Banerjee
Debnath Mukherjee
TCS Innovation Labs, Tata Consultancy Services Kolkata, India, 700091 Email:
[email protected]
TCS Innovation Labs, Tata Consultancy Services Kolkata, India, 700091 Email:
[email protected]
Abstract—As the world is getting more and more connected, a requirement for a connected notification system has emerged. In this paper a universal notification system namely UNS based on stream reasoning is described that not only meets the requirement of knowledge sharing among applications but can cater to different varying and custom scenarios, is flexible and semantic web compliant. Experimentation was done considering a meeting use case in a simulated condition on real data of smart city, and the experimental results were found to be promising.
Static Data
I NTRODUCTION
Smart notification system is an important service envisioned in smart cities. Although the world is being foreseen to be more connected than ever before, however notification systems that use the collective knowledge across multiple domains are as of now non-existent. So for each scenario, a new system needs to be built and maintained. The users has to get accustomed with the interfaces of different applications and systems which is cumbersome. To tackle the issues raised above, concept of universal notification system is introduced. Definition of Universal Notification System (UNS): A notification system that has one point of interface for administrators, developers and end users; supports integration and interplay of any type of notification application and use cases; can timely process massive, heterogeneous data (including streams); and can serve a large number of concurrent users. In UNS, functionally similar or closely inter-related applications should be grouped together to take advantage of common shared data and inter-dependence, while dissimilar applications should be grouped far apart. However, there should be a connection between the groups for occasional dependency. This follows the software engineering principle of high cohesion and low coupling. As can be seen from Fig. 1, varieties of data enter the system and the system interfaces with a variety of users. M denotes a functionally cohesive module containing a collection of interrelated Applications (App). There is a way to transfer data between different modules that may lie distributed. The realization of UNS is a challenging problem as (a) individual applications will have their own format of static / slowly changing data (b) analytics on vast amounts of data has to be carried out with minimum latency (c) the appropriate strategy for data exchange between applications needs to be found (d) fast conversion of streaming sensor data (which is heterogeneous) into uniform format is desired for further analytics (e) expression of logic by applications needs to be uniform for logical connectivity. This paper describes an elegant solution to realize UNS by a synergy between stream reasoning [2], information extraction and enabler technologies.
Mn
App 1
App 1
App 1
App 2
App 2
App 2
App ’p’
App ’q’
App ’r’
Dynamic Data
Slowly Changing Data
Fig. 1.
Keywords—notification system, stream reasoning, linked data
I.
M2
M1
Admin
Developer
UNS
End User Data Passing
Generic Architecture of Universal Notification System
II.
R ELATED W ORK
Considerable research has been carried out on notification systems [3] that are targeted at specific domains. The main problem in the existing systems is that they exist as disconnected solutions. Moreover, most of them either do not address or partially address the needs of semantically rich context-aware and personalized notifications. The most closest work in this regard is [1], which introduced a public alert system based on stream reasoning; however the system lacked both the learning aspect of personalization as well as support of dynamic logic update; and was targeted for only one domain. To the best of our knowledge there exists no system having all of the following properties in combination that the proposed UNS have: a) connected solution b) context-aware c) personalized d) knowledge based e) ease of changing logic.
III.
D ETAILS OF UNS BASED ON S TREAM R EASONING
Abstractly, the underlying principle is as follows: user’s profile data and geo-spatial data collectively called the background knowledge is combined with users’ dynamic context and sensor data in a dedicated working memory (WM) of the system; reasoners run on that WM to entail facts; queries are run on this WM to match patterns; and if a match is found consequent action like user notification is taken. As seen from Fig. 2, the User, Developer and Admin modules form the interface between the Stream Reasoner (SR) and the end-users, developers and administrator respectively. The data entered in the interface is available to all applications post approval. As there is no hard-coded logic in the SR interface (which is based on rules and queries), this makes way for dynamic addition / deletion / updating of application logic. From the external world, any knowledge entering SR (like social web data, context, sensor data, user profile data and static knowledge) has to go through the Knowledge Unification Layer, where the raw, semi-structured and structured data is converted to a uniform structured form namely RDF by techniques such as machine learning and information extraction as per need. The system has connectivity with the Semantic Web and is capable of reading data over URIs. The contextual learned behaviour of
User Module Update profile data and verify contexttual learned data Subscribe to specific applications, Also recieve alerts in the UI of mobile device(s)
End User
Fig. 2.
MA n
SR
MA 1 U11
Knowledge Manager Configuration and Settings
U1p
Knowledge Store
Un1
Unq
Admin Module Manage system settings like start / stop; plug data sources; manage repository of queries & rules; manage the apps
Rules and Query Repository Knowledge Unification Layer
Developer
Dynamic Context and Streaming Data from Hard and Soft Sensor
Web (Social & Semantic)
Admin
Create apps, Manage app specific registered rules & queries; select data sources needed, plug/unplug ontolgies
Learnt Behavior
Static Data (heterogenous)
Developer Module
Architecture of UNS based on Stream Reasoning
the user like places often visited under some context is stored in format for future use. The SR is divided into Memory Areas (MA) each for functionally similar applications which are actually the WM where static and dynamic data exists; registered rules and queries are run on corresponding MA to produce results. As seen in Fig. 2, MA1 is a memory area containing inter-related use case specific data U11-U1p and shared data. An entailment by firing rules for U11 may trigger a rule for U12 and so on. MA2 is another memory area tailored for other functionally similar use cases. This approach comes in handy as functionally dissimilar applications sometimes need some knowledge of the other. As an example, consider two use cases namely electricity supply in MA1 and gas supply in MA2. Each use case has separate notification types say consumption alerts like alert if the user consumes more electricity than pre-set. However such an alert will not come at a low pre-set threshold if MA1 knows that gas supply has stopped due to sudden strike (which is a rare event) from MA2, and high electricity usage is normal under these circumstances. Each of the MAs may lie distributed as per need. The Knowledge Manager is responsible for passing knowledge to the MAs and communication between MAs (that is achieved by registering queries to find patterns of facts for use in other MAs). Background knowledge is persisted in Knowledge Store while a portion is loaded on demand in MAs. The Repository comprises of registered rules and queries. Each registered query has a listener attached to it for result processing and conveyance to relevant users. IV.
UNS IN ACTION
To demonstrate and test the functionality of UNS, a J2EE based software system was developed. Apache Jena1 is extended by a stream processing layer and additional features to realize the stream reasoning system. In the meeting use case (Fig. 3), the host arranges a meeting and invites the attendees in an online calendar like Google Calendar. Here the affected attendee will get the notification because of the public alerting app’s registered logic, and the other attendees will get the notification because of meeting app’s registered logic. This demonstrates the concept of functionally cohesive apps of UNS. A simple example follows. App 1 and 2 belonging to the same memory area shares common ‘event’ data, where as the data about meeting is specific to App 2. The knowledge entailed in App 1 is of use in App 2 as seen from the Jena1 rules and SPARQL2 queries used to express application logic:
Fig. 3. Meeting use case simulation screen where real recorded data is being played back to simulate the behaviour of UNS (Annotations are in red colour)
App 1. Personalized Alert Application Logic:Query: select ?person ?event where {?event e:affects ?person} Rule: (?person s:isAt ?loc) (?event s:isAt ?loc) → (?event e:affects ?person) App 2. Meeting use case Application Logic:Query: select ?meeting ?event ?person where {?person e:isAnAttendee ?meeting . ?event e:affects ?person} Rule: Not needed as App 1 (of same MA) includes the rule. V.
E XPERIMENTS AND R ESULTS
The system was tested on a 3 GHz Intel Core2Duo machine with 2 GB RAM. The background knowledge included OpenStreetMap3 geo-spatial data of Washington D.C., USA and simulated profile data of 2,000 citizens. UNS monitored live crime feeds of Spotcrime4 while simulated location context of citizens was posted every 10 s for each citizen. Real recorded data was played back to imitate events in the city so as to get matches of events with user’s data. The response time and processing time obtained are 2.5 s and 8.5 ms, respectively. The response time is the average difference between an event actually happening (detected by the sensor, that may be hard or soft) and the time it is shown in the UI of the relevant user (this is inclusive of all the steps in between such as information extraction). The processing time is the average time taken to fire rules and run corresponding query due to insertion of an event data in MA. In context of the state of the art in stream reasoning and UNS requirements, the results are promising. R EFERENCES [1]
S. Banerjee, D. Mukherjee, and P. Misra, “What affects me?: a smart public alert system based on stream reasoning,” in Proceedings of ICUIMC 2013. ACM, 2013, pp. 22:1–22:10. [2] E. Della Valle, S. Ceri, F. van Harmelen, and D. Fensel, “It’s a streaming world! reasoning upon rapidly changing information,” Intelligent Systems, IEEE, vol. 24, no. 6, pp. 83–89, 2009. [3] U. Meissen and A. Voisard, “Current state and solutions for future challenges in early warning systems and alerting technologies,” in Advanced ICTs for Disaster Management and Threat Detection. IGI Global, 2010, vol. 83, pp. 108–130.
1 http://jena.apache.org
3 http://wiki.openstreetmap.org/wiki/Downloading
2 http://www.w3.org/TR/rdf-sparql-query/
4 http://s3.spotcrime.com/cache/rss/dc.xml
data
