A DSL for business intelligence monitoring

Social media has provided the business community with a unique and unprecedented opportunity to engage with their customers, critics, competitors, etc. Yet, this comes at the costs of continuously monitoring the various fora where the business name may be mentioned, where questions may be posted, where products may be compared, etc. Effectively dealing with social media in a world where a maximum of a few hours is the expected response time, is a challenging task. Focusing in particular on Facebook, a typical business would have its own page as well as a strong interest in pages on which their products may be discussed or advertised. Typical events which are relevant for a business might include any mention of the brand or a product, an advertising post by a competitor, a comment by a customer (particularly if negative or if a question), and so on. To make the task of checking for these events manageable, dashboards [1, 3, 2] are available allowing users to specify events of interest so that a notification is received when such an event is detected (e.g., a notification when more than five comments are awaiting a response). The problem with existing tools is that while they allow the specification of a number of events of interest, they do not offer the flexibility which might be required by the business in question. For example one might want to prioritise the notifications in order of urgency (e.g., a comment from a new customer might is given precedence over that of an existing customer); alternatively one might want to group them into batches (e.g., a notification per five comments unless a comment has been posted for more than three hours). Such flexibility usually comes at the price of a tailor-made solution which is generally expensive both if developed in house or by a third party. One way of allowing a high degree of flexibility while providing an off-the-shelf solution would be to present a simple interface which would allow a business intelligence analyst the flexibility to express the desired events for notification. These would in turn be automatically compiled into Facebook monitors without any further human intervention. While an automated compiler would struggle to handle natural language descriptions and a non-technical business analyst would struggle with a programming language, a domain-specific language presented to the user as a controlled natural language (CNL) [6] may act as an intermediary: it provides the feel of a natural language but constraints the writer to particular keywords and patterns. Furthermore, using standard techniques to allow the user to write their scripts using particular user-interfaces (e.g. pull-down menus or fridge magnet style) bypasses the problem of syntax errors, thus making their writing more accessible to a non-technical audience. Based on interviews with two business analysts, such a CNL should allow the user to specify patterns such as: (i) Create an alert when the service page has a post and the post contains the keywords fridge, heater, and freezer. (ii) Create an alert when my

[1]  Martin Leucker,et al.  A brief account of runtime verification , 2009, J. Log. Algebraic Methods Program..

[2]  Leonardo Mariani,et al.  Run-Time Verification , 2004, Model-Based Testing of Reactive Systems.

[3]  Gordon J. Pace,et al.  LARVA --- Safer Monitoring of Real-Time Java Programs (Tool Paper) , 2009, 2009 Seventh IEEE International Conference on Software Engineering and Formal Methods.

[4]  Tobias Kuhn,et al.  A Survey and Classification of Controlled Natural Languages , 2014, CL.