Introduction

The goal of the Android-based POETS client (or client henceforth) is to be agile with respect to changes to the parts constituting the POETS architecture. Changes or additions to contracts, report-functions, rules, or the underlying ontology should not imply major work on updating the client.

The most basic part of the POETS architecture is the ontology defining the entities which one can talk about in contracts, report-functions, rules and so on. Therefore, a tool has been developed to translate ontology entities into Java classes. Besides containing the fields defined in the ontology, the generated classes also contain methods for conversion to and from XML conforming to a certain xsd.

The client makes use of the Java representation of the ontology entities for visualization and user input. For input, there is a Java class that given a Java class (AndroidGUI) representing an ontology entity, produces an Android View that allows the user to enter the fields needed of the ontology entity. For visualization, there is a Java class (AndroidVisual) that given an object of type “Java class representing an ontology entity” produces an Android View that visualizes to the user the fields defined in the ontology based on the type of the object.

The classes AndroidGUI and AndroidVisual are generic because they treat all ontology entities equally. However, most ontology entities has some meaning to users that could be reflected in the visualization and input of such entities. I.e. the visualization of a “Customer” entity could additionally include a pictogram of a person to convey to the user that a Customer entity is actually a person. The visualization could even try to fetch additional data such as pictures of the customer in question not already present according to the entity definition. Likewise for input of a Customer. In its current form a Customer entity only contains a field “name” which is a string. The AndroidGUI could use the information that fields named “name” in a “Customer” (or any subtype hereof) should be turned into an input-control suitable for entering names.

What we seek is therefore visualization of and input controls for the Java representation of ontology entities specialized to the particular ontology in question.

Projects

The following is a list of projects that approach the task described above.

• Select a number of (high-level) entities from the ontology and construct really clever ways of visualizing and inputting those concepts. However, the caveat is that that changes to the definition of the selected entities should not break your clever code. Of particular interest is the visualization of “Contract” entities because they have associated temporal behavior as defined in by their corresponding contracts in the the contract language. E.g. one could choose to visualize a “DeliveryContract” on a map with all the delivery destinations pin-pointed on the map.
• Integration of POETS contacts. There is an ontology entity called “Agent” which has amongst others “Customer” as subtype. The Android platform also as a concept of contacts and it would be beneficial to connect the two concepts such that when (e.g.) a “Customer” entitie needs to be entered by the user, she can simply pull all relevant information from the contact available on in the contacts stored on the phone.

A valuable source of customer related information are email conversations. It is therefore natural to integrate email sources into POETS. More specifically, the task is to feed incoming and outgoing emails from a set of email accounts into POETS. In order to make email messages available in the reporting system, the email messages are supposed to be fed into the system by generating according events in the event log.

Due to the architecture of POETS this integration can be performed without extending or changing the system itself. The email system simply acts as a client that feeds events to the system. This project involves the following subtasks:

• implementation of collecting incoming an outgoing email messages from a given set of email accounts
• implementation of generating proper events to feed the email messages into POETS
• write proper definitions in the ontology language that capture email messages
• write reports that enable to connect customers to their email conversations

Due to the event-driven nature of POETS’ architecture, most strikingly manifested in the complete absence of a traditional relational database, reporting functions play a central role in POETS. A reporting function is a computable function that extracts relevant information (then called “report”) from the event transaction log. That is, a reporting function makes a certain piece of information about the state of the system which is implicitly encoded in the history of events explicitly available.

In order to facilitate describing these reporting functions and making this also available for domain experts, POETS provides a domain-specific language for describing reporting functions. This reporting language is a purely functional programming language which allows to describe functions extracting information from the event transaction log in a declarative manner.

In order to keep theoretical reasoning about the language concise and to simplify the implementation of optimisations, the language only provides basic operations, which are considered sufficient for the domain in question. This however, makes writing reporting functions sometimes cumbersome. The goal of this project is to overcome this deficit by implementing a set of syntactic extensions to the reporting language such as list comprehensions for convenient list processing and dynamic typing operations for dealing with POETS’ data ontology. This goal is supposed to be achieve by reducing the syntactic extensions to the core language, or alternatively by an optimised implementation which is then tested against the intended semantics. This involves the following subtasks:

• parsing the extended syntax using a monadic parser combinator
  library
• extending the definition of the reporting language’s abstract
  syntax using extensible expression data types (“data types a
  la carte”)
• implementing the type inference for the added syntax using
  the provided monadic infrastructure
• implementing the transformation of the added syntax to the
  core language by making use of the used extensible expression
  data types
• providing an alternative direct implementation of the
  additional language features
• providing tests for checking the direct implementation
  against the transformation-based one

Another practical issue of the reporting language is the readability of the types inferred by the type system. The type system employs a number of type constraints for capturing subtypes, overlapping record names and other aspects of the reporting language. The inference system usually infers types with a confusingly large number of type constraints. Typically, these constraints can be rewritten to a substantially smaller set of constraints, in many practical cases even the empty set. The second part of this project is concerned with the implementation of a simplification algorithm for type constraints that transforms a set of type constraints to a minimal equivalent set of type constraints.

During the project the following skills should be developed:

• writing “real world” Haskell code in a larger software project
• working with a monadic parser combinator library
• implementation of a type inference algorithm
• constraint analysis and transformation
• writing monadic functions using monad transformers
• using extensible expression data types (data types a la carte)

The resulting Haskell code has to be integrated with the current implementation of POETS.

(Key) Performance Indicators are measures used to give an insight into how well a business is performing. KPIs vary from business to business and often across roles within a business. While management is usually interested in aggregate information such as bottom and top lines (and their quotient) a sales person might be more interested in his own performance in relation the top contenders in his competition for getting a bonus.

In both cases ubiquitous access to real time KPI data is of immense value.

The purpose of this project is to device and implement a system that allows end users of POETS to visualize and maintain the results of certain reports (with predefined input) as widgets (enlarged interactive icons) directly on the Android Home Screen. The system should allow users to select the reports they want to monitor along with threshold values and methods of visualisation (e.g., speedometers, stoplights, graphs etc.).