Objectives
The objective of a Liquid Publication management system is to provide users with straight forward means for the specification and the automatic execution of the processes concerned with the creation, dissemination, and evaluation of research work. In other words, the aim is a user friendly system for managing research work.Examples of research related processes are creating and running conferences, managing projects, writing papers collaboratively, compiling books, and so on. Each of these processes is defined by a set of rules. For instance, rules could address who is allowed to create, modify, assess knowledge (which we refer to as SKOs in the Liquid Publications project). Rules may also specify deadlines for actions, the accepted order of actions, and so on. We refer to these rules as the specification of the process model.
In addition to the specification of research related process models, the management system should also provide the automatic creation and update of a web-based user interface for the related researchers (or personnel). Existing examples of this are current conference management systems, such as ConfMaster and EasyChair. However, while existing conference management systems are hardcoded and the interface requires a manual updated every time a change occurs, the LP management system proposes an automated generation and update to the web-based user interface, eliminating the need for manual modifications. To achieve this, the specification of process models needs to be enriched with information about user interfaces.
LiquidPub Management System
Design
To achieve the objectives above, the user needs to specify the process model and enrich it with information about user interfaces. Ideally, we aim at providing a straight forward user interface that would allow the user to produce the specification through a simple drag-and-drop. Hence, we say the process model can be specified as a transition graph and an additional mapping file is needed to map the states of the transition graph to a set of 'views'. This is because each peer laying a specific role in the process model should see a different set of views, based on its current state in the model. Naturally, a library of 'views' should also be provided to allow the user to choose from.
Implementation
To implement the above, we make the following choices:- process models are implemented as Electronic Institutions (EI), since the Islander tool already provides an easy to use user interface for the specification of process models through a simple drag-and-drop
- the library of views will essentially be a library of widgets
- the file mapping between states of the process model and a set of views is specified in XML
Additional Information
We note that this work is still in progress. Currently, a presentation of our work is available here.For any further questions, please contact Carles Sierra.