| |

A Calendar of Events - Architecture and Experiences

Stefan Lüttringhaus-Kappel and Dirk Schulz

Institut für Informatik III, Universität Bonn, Germany
E-mail: {stefan,schulz}@uran.informatik.uni-bonn.de

July 26, 1996

Abstract:
We present Announce, an electronic calendar of events. Announce is an information system announcing colloquium and seminar talks. The architecture is quite general and hence suitable for other applications as well. Announce has both an email and a WWW interface for users and information providers, i. e. seminar chairpersons. The internal database uses straightforward logic programming techniques to model the tree-like hierarchy and inheritance of data and formatting attributes in an object oriented style. We also discuss experiences made with several approaches and tools during the development process.

1. Introduction

Announce is an electronic calendar of events. The starting point was the desire to have an information system which would inform interested people inside and outside the university about colloquium and seminar talks and similar events, so one would no longer inadvertently miss an interesting talk.

The traditional media for such announcements are the department's bulletin board and the distribution of printed lists and invitations through internal mail. This is reflected in modern electronic media; the World Wide Web (WWW) pages are the bulletin boards -- you have to go there and watch, while email reaches you more directly and (hopefully) just in time.

A discussion of the requirements of an electronic calendar of events for our department revealed that we would need all of the media mentioned above: paper, WWW, and email. The role of the WWW is to show announcements as soon as they become available, the printed lists on the bulletin board serve their traditional purpose for those without the time to use the internet :-), and an email message reminds people about today's talks.

So far for those who seek information. Considering acceptance on the side of the provider of information, e. g. a seminar chairperson or a faculty secretary, it is important that no additional effort is required for maintaining the new information sources, i. e. all output, paper and paperless, must be derived from a single database. Moreover, to avoid any bottlenecks, it is absolutely necessary to have a decentralised administration of the various series of lectures.

In this paper we describe the architecture of a Prolog based information system which has been developed with the above requirements and constraints in mind. We also discuss the experiences made with certain approaches and tools during this design process.

2. The System Architecture

Figure 1: Tree Structure of the Database

attributes(root, wpermission, list).
attributes(root, talktablehead, template).
attributes(root, talktablebody, template).
attributes(root, talktablefoot, template).
...
attributes(root, talkreminder, template).

attributes(institution, director, text).
attributes(institution, latexpreamble, text).
...
attributes(institution,X,T) :- attributes(root,X,T).

attributes(seminar, headline, text).
attributes(seminar, location, text).
attributes(seminar, time, time).
attributes(seminar, chair, text).
...
attributes(seminar,X,T) :- attributes(institution,X,T).

attributes(talk, author, text).
attributes(talk, subject, text).
attributes(talk, abstract, text).
attributes(talk, date, date).
...
attributes(talk,X,T) :- attributes(seminar,X,T).

% Inheritance Types

inherit_type(comment, X) :- !, X = none.
...
inherit_type(wpermission, X) :- !, X = append.
inherit_type(remindemail, X) :- !, X = append.
inherit_type(_, copy).

Figure 2: Some Attributes of Database Entries

In this section we describe the data model, the database, and transactions both through the email and the WWW interface.

2.1. The Database

The database contains four types of entries:

talks
seminars/series
institutions (faculties, research groups, ...)
a special root node

All entries are organised in a tree as indicated in figure 1. The class hierarchy

root institution institution seminar talk

restricts parent relationships in the database tree; talks are always leaves, talks are children of seminars, seminars are children of institutions or of the root (institutions are optional), and the special root node containing general settings resides always at the top.

Attributes are inherited along this hierarchy in an object oriented style. Each level adds its own attributes (some are shown in figure 2), together with the appropriate data types. In addition to the usual data types, Announce requires a date and a time data type, both supporting free format entry, canonical internal representation, e. g. date(1996,6,14), and canonical output format.

There are several types of inheritance, including

none (don't inherit)
copy (take value from parent)
append (append values from node and parent)

The inheritance type of an attribute is declared in a Prolog relation inherit_type/2 (also in figure 2). The method copy is the default, as this is the most frequently used method. The inheritance mechanism is implemented in Prolog, using only a few more clauses. It is easy to extend and/or modify this mechanism to match the requirements of future applications derived from the current Announce system.

2.2. Transactions

Transactions are accomplished by sending orders to the Announce system, either via email or, in the new release, through the WWW interface. Orders can be divided into two groups, those changing the database state (create/update/delete) and hence requiring write permission (also an inherited attribute), and those merely extracting information.

Originally, transactions could be initiated by email only, so we defined a simple markup language to describe transactions. We introduce the major concepts by example.

  [command]create talk postersets in poster[/command]
  [date]4.9.96[/date]
  [subject]Applications of Efficient Lazy Set Expression[/subject]
  [author]Stefan L"uttringham-Kappel and Dirk Schulz[/author]
  [abstract]
  We add more expresive power to Prolog in the form of lazily evaluable
  set expressions. The need for lazy set expressions arise from the
  design of integrated logic+functional programming languages.
  ...
  [/abstract]

Figure 3: E-mail Message to Insert a Talk into the Database

In figure 3 a talk is inserted into the database by creating a new node. Updates work similarly (update instead of create), moreover it is sufficient to send only the values of attributes to be modified. To receive the contents of node InfIII (an institution) by email, we send the command

[command]submit node InfIII in root[/command]

The answer is in the format of an update command, so we may edit it and send it back in order to update the database:

  To: stefan@uran.informatik.uni-bonn.de
  Subject: VKAL-Query
  
  [command]update institution InfIII in root[/command]
  
  [seminarhead]
  <HTML>
  <HEAD><TITLE>Universitaet Bonn, Institut fuer Informatik III, Seminare
  <!--#include virtual="/inc/header-III.shtml3" -->
  
  <CENTER>
  <H2> Seminare und andere regelm&auml;&szlig;ige Vortragsreihen </H2>
  </CENTER>
  
  <DL>
  [/seminarhead]
  ...
  [institut]Institut f"ur Informatik III[/institut]
  [latexsubstyle]inf3[/latexsubstyle]

Figure 4: A Printed Announcement

To receive a LaTeX file of a talk or a seminar, respectively, we say

[command]submit announcement postersets in posters[/command]

[command]submit announcement posters in InfIII[/command]

The LaTeXed result of the latter is shown in figure 4.

Transaction processing is completely done in Prolog. Update transactions modifying the database used to trigger the generation of prefabricated pages in the previous Announce system. It is no longer necessary in the new approach, because pages are generated on the fly.

2.3. The Web Interface

2.3.1. Transactions through the Web

Figure 5: Seminar Overview in Navigation Mode

Figure 6: A Talk in Navigation Mode

Figure 7: An Edit Mask for a Talk

The tree structure of the database is reflected in a tree of hyper-linked Web pages in an obvious way. In the update mode, we distinguish navigation pages (figures 5 and 6), which are used to reach the node to be updated, and edit masks (figure 7). For each node there is a navigation page and an edit mask.

Submitting the contents of an edit mask immediately updates the database; the changes are reflected in all future requests to the Announce system.

2.3.2 Formatting Documents

Both HTML and LaTeX documents can be formatted in a flexible way to conform with local conventions (WWW page layout, department letterhead).

The Announce system uses templates for output documents; the templates are ordinary attributes of the respective node types. We are going to briefly discuss two aspects of the template system. First, we give an example of the substitution mechanism used to fill in the variables of a template. Template parsing and substitution is done with a Prolog DCG.

2.3.2.1. Example

In the context of a list of all talks of a series, a link to a page containing a single talk is created only if we have an abstract for the talk:

%! if %abstract% == %!!% 
   then 
     %!<I>%subject%</I>!% 
   else 
     %!<A HREF="http:~announce/abstracts/%node%.html">
       <I>%subject%</I></A> !%

The syntax, which appears to be a little bit ugly on first sight, was designed to be distinguishable both in HTML and LaTeX source text. %attribute% inserts the value of an attribute, while %!...!% act as parentheses for more complex constructs.

Second, there are two types of documents wrt. the template system. A talk page, for example, uses a single template describing the whole page. On the other hand, seminar pages contain a whole collection of references to talks, requiring templates consisting of three parts: the top, the iterated part, and the bottom. LaTeX documents, for example, are generated from the template attributes latextalktablehead, latextalktablebody, and latextalktablefoot. Similar attributes sets exist for HTML and ASCII (email) seminar pages.

3. Implementation

We used the ECLiPSe Prolog system by ECRC GmbH [5] for the implementation of the database system. All the database operations, including OO-style inheritance are formulated very easily and very elegantly in Prolog, of course.

Figure 8: Architecture of the Previous Announce System

3.1. The Previous Announce System

More than two years ago the first version of the Announce system was brought into service. Incoming email is piped into a small shell script, which invokes the main ECLiPSe process. The shell script also handles locking, so only one ECLiPSe process is running at a time, and waiting, i. e. serialisation of transactions.

The ECLiPSe process loads the database file (about 250 kBytes) and either sends back the appropriate email message or updates the database and all affected HTML-pages, and rewrites the database file. This being a quite conservative approach, it has a couple of advantages nevertheless:

The system runs very stable; there are no daemon-like server processes which could refuse to answer.
The access to the prefabricated pages is very fast and completely independent from the Announce system.

On the negative side, responses are quite slow: ca. 10-20 seconds for returning email, and up to two minutes for the updates of all affected HTML pages. This is, however, no problem at all for the intended field of application.

Finally, the distribution of email reminders is delegated to the Majordomo system [2], which is in use on the departmental server anyway.

3.2. The New Announce System

Figure 9: Architecture of the New Announce System

Writing email messages with all that markup appeared more and more cumbersome to the users of the announce system. So recently we extended the Announce system to allow updates through a WWW interface. The pages required for navigating through the tree to the node to be updated are created on the fly, as well as the input form containing the current values of the node.

Obviously, this approach is not restricted to the update mode; we now consistently generate all HTML pages dynamically, for both retrievals and updates. Prefabricated pages are no longer stored on the file system (figure 9).

The database is kept in an permanently running ECLiPSe process which is listening on a socket. Each request from the WWW client for a node is passed to this `database server' process via a very small CGI script (written in Perl). Database update requests are performed in the database server for immediate visibility of the results. In order to achieve persistence, the database state is saved to disk after each update transaction.

3.3. Evaluation of Tools

Prolog is the language of choice for the database portion of this and similar systems; it is very good at object oriented modelling, inheritance, complex objects, etc.

In both evolution steps of the announce systems we used ECLiPSe also to generate HTML code. The previous system was based on templates (see section 2.3.2 above) supported by a relatively simple substitution mechanism. We decided to use html_pl by D. Cabeza and M. Hermenegildo [1] in an evaluation prototype of the new system. html_pl allows structural representation and structural manipulation of HTML code as Prolog terms. As outlined below, however, it turned out that using a text-based substitution mechanism is preferable for our purposes; so we do not really need structural manipulation of HTML code.

Our experiments in the Announce project and even more in a number of other projects leads to the statement, that HTML code is best generated from HTML template files prepared by an ordinary text editor. Having used various more or less simple substitution schemes in these projects, a substitution language summarising all our experiences is under development and will soon enter the test stage.

Prolog deals with database objects (Prolog terms) appropriately, unification being an adequate powerful mechanism, but a quite different situation arises for textual representation, e. g. Web pages. When it comes to string processing, scripting languages like Perl [6] with powerful string manipulation features and textprocessing functionality easily beat Prolog's string built-ins. Perl is both very powerful at text manipulation and almost complete wrt. system access; so its widespread use in CGI programming is not surprising at all. Note that we are not talking about formal or natural language parsing here; rather think of character set conversion, stripping white space, and regular expression substitution, and so on.

As a result of these observations, our Announce systems uses both Eclipse and Perl quite happily, each in the domain where it is strongest.

4. Related Work

Our Announce database can be viewed as a deductive database, which implements some object-oriented features using rules. As such this work is directly related to other approaches interfacing deductive or object oriented databases to the World-Wide Web. Just one example is ObjectForms and WebConnect for ObjectStore [3], not to speak of the efforts of nearly every relational database vendor to built Web interfaces for their products.

The way these systems connect the database to the Web is comparable to our approach, i. e. a traditional client/server design. A different approach is to bring query processing directly into the WWW client. This method is used by S. W. Loke and A. Davison [4]; they integrate Prolog into a WWW-Browser. The user has the opportunity to combine Prolog databases from several places and query results are displayed as HTML pages.

5. Conclusions

The Announce system is now in use for more than two years and most of the goals mentioned in the introduction have been achieved. It turned out that the database designed as a tree with OO-style inheritance was a fortunate design decision. Today the system is being used for announcing seminar talks only, but the design allows a much wider variety of applications, announcing regional cultural events, for example, or maintaining a database of conferences or `call for papers'.

Due to our recent extensions the whole functionality of the system is provided through the Web interface. There is no need to learn a query language any longer, which greatly improves acceptance by the users.

5.1. Future Work

The next step will be the further automatisation of the announcing process. The speaker herself will enter the details of her talk, the moderator of the respective series just has to acknowledge the submission and the announcement is released to the public.

Other options for future developments include:

Extending the system to use a distributed database as a further step of decentralisation.
Allowing multi-media material in announcements, to further extend the applicability of the system.
Implementing stronger security mechanisms, for example PGP signatures, where the Announce system will maintain a database of public PGP keys of all people with any form of extended permissions. All incoming requests will be checked wrt. their PGP signature. A matching signature unambiguously identifies the sender. This information will be used to determine the exact access rights to the database and hence whether the transaction is legal.

References

1: D. Cabeza and M. Hermenegildo. html.pl: A Simple HTML Package for Prolog and CLP Systems, 1996.
http://www.clip.dia.fi.upm.es/miscdocs/html_pl/html_pl.html.
2: D. Brent Chapman. Majordomo: How I manage 17 mailing lists without answering ``-request'' mail, 1992.
ftp://ftp.greatcircle.com/pub/majordomo/.
3: Object Design Corp. Objectstore objectforms.
http://www.odi.com/products/onweb/oforms.html.
4: S. W. Loke and A. Davison. Logic Programming with the World-Wide Web. In Proceedings of the 7th ACM Conference on Hypertext, pages 235-245. ACM Press, 1996.
http://www.cs.unc.edu/~barman/HT96/P14/lpwww.html.
5: ECRC Eclipse Team. ECLiPSe 3.5 User Manual, 1996.
http://www.ecrc.de/research/projects/eclipse.
6: Larry Wall. Perl Programmers Reference Guide, 1995.
http://www.perl.com/perl/info/documentation.html.

Footnotes

...pages.

The scheme is a little bit more complicated than described above; headers and footers are further divided into several attributes to facilitate uniform appearance wrt. letterhead and graphical design by just re-using, i. e. inheriting templates.

| |