Implementation of the Information system

The information system physically consists of server computers. Clients are found among several institutions, as figure 1 shows. The info boxes are computers running Mosaic in a kiosk mode. They do not have a keyboard, just a trackball so they can be placed at unattended places for access (nearly) around the clock.

Figure 1: The information system embedded in its environment. The arrows indicate the direction of data flow.

Information provided for students:

There is a wide range of information meeting the demands of students. In addition to help for organizing study students find information for support during study including a location tool to help to find the location of all staff and public institutions.

Now it is possible, to register for examinations. It does not matter where in the world you are, if there is a connection to the internet. As registration for examinations is mostly during vacation, students do not need to come to Mannheim for this.

To help users to find desired information there are graphical overviews as well as a contextsensitive multiple-keyword search. This is realized with a fast keyword search on all documents in the structure. It is not only a simple keyword search on the words contained in the documents but there is a context for each document. The context is defined by a set of keywords appended to each document as a comment. So the context is invisible but leads to a better specification of documents.

Implementation of the administrating system

There is no uniform hardware environment at the institutions of the faculty. The chairs work with three types of computers: PCs, MACs and UNIX- workstations. They are connected to an FDDI backbone and run Windows for Workgroups, Novell 3.1, Apple Talk and TCP. So they do not have many things in common except that they can run Mosaic and electronic mail.

For an uniform environment, there is either the possibility to run X-Windows on their machines or to build an application for the three types of computers - or to use Mosaic itself as a front end for administrating tasks.

Using X-Windows is not feasible because of too much technical and financial efford. Implementing a client for three systems is too labor intensive as well. Fortunately there is Mosaic as a client with its powerful rendering facilities and fill-out-form support.

There are two ways to give information to the system: Either by e-mail or by use of the administrating system.

The e-mail placer: Tasks with the requirement for good editing and text formatting facilities can be done with a text processing software (like Word and its related products - it is used by 90 % of the chairs.) There are announcements from the chairs concerning dynamic information like changes of dates or places for courses and seminars as well as announces for student jobs or new topics for dissertations that can be formatted for a better look.

With Word you can send documents just by activating a menu item, as Word triggers your e-mail program and includes your document. An e-mail placer receives the mail, recognizes the format of the sent document and starts up the appropriate filter to convert it into HTML. Then it puts the announcements to the appropriate places in the information structure according to sender address and subject of mail.

Announcements will be removed when not required anymore.

E.g. an announcement for a dissertation will be removed automatically after someone is found to work on it and gets registered for it. (The mechanism will be described later).

WWW for database applications: The different groups of users (students, chairs, deans office) need to have different applications. An application is implemented as an URL to a fill-out form.

After clicking on the application link the server gives back your set of applications according to your belonging to a group, that is determined by your adress. As a member of a group with privileged access, you have to send a password for your legitimisation. It is valid until you leave the administrating section.

Following table show the available applications for the different groups:

Students                     Staff of the chairs          Staff of deans office                                     

Application for exams        Making lists of staff        Supervising of registration  

Retrieveal of results        Administration of            Automatic creation         
                             dissertations, seminars      of room indexes.    
                             and exercises

                             Inventory                    Inventory

To have these information not only on the screen you are able to export the results of your query in several formats: Tex, Word and ASCII. Excel and Ragtime ist planned.

For this export feature there is a format button on the formulars and in order to your choice the document will be transferred in the format of the relating mime-type extension. This makes the client machine start the appropriate program.

Requirements for the server: To provide the appropriate output format, DB queries results have to pass a filter to meet the requirements of of the output format (i.e. Ragtime, Word, etc.).

For the client: The client has to be configured to run the corresponding programs and must have these programs installed on the machines.

Maintenance aspects

This project describes the attempt to build a perpetual motion machine. Usually provided information with WWW gets out of date, unless you care about periodic update. In terms of the machine: Unless you do not put some energy into the machine, it will stop.

Usually you have to have a person for a certain range of hypertext to maintain. This person collects the information from several sources. In the process of maintenance the maintainer has to ask the sources for up to date information. This is unneccesary due to electronic data processing. Another way of information maintenance is to give the task to the sources of information. The maintenance consists only in the use of the administration system plus the automatic insertion of dates in the hypertext. You cannot involve all the sources the information comes from, but main source of information comes from the chairs and the deans office.

So certain dates can be maintained this way and others not.

According to information maintenance there has to be made a distinction of information under qualitative considerations. There are three categories: Long term information, that gets updated every couple of years, medium term information with an update period of every half a year and short term (dynamic) information, that can change every day. To reduce the efford of integration we only consider the short and medium term information for automatic maintenance. Fortunately it is only long term information, that comes from the sources as degree course scheme, curriculum or the main fields of research and teaching of the chairs. The system cannot (and will not) be aware of changes of these facts.

Meta Database for automatic maintenance

The central issue of the system is, how a relational database can be connected with information in the hypertext structure in order to keep it up to date. For this purpose a so-called Meta DataBase (MDB) does the job.

There is information in HTML documents, where the contents consist of pure text. And there is information consisting of a so-called informal part with data embedded.

The first kind of information is hard to create automatically, as you need text generators etc. For the second kind of information there is a way of updating:

The beginning end ending of a data field within a hypertext document is marked with a certain comment, that represents the key for the MDB. Each entry in the database is linked with a key in a one to one (1:1) relation. The administration of the keys (destroying and providing new keys) is task of the Database. When there are changes in the relational DB, the MDB will be triggered to look for changes that have to be done in the HTML structure. I.e. every writing process on DB triggers a daemon, that asks where the changes have to be done in the hypertext.

But what happens, when there is a delete or a new entry of a staff member? In this case a lot of things have to be done, as this process affects the hypertext structure. In the case of deleting a staff member in the DB, her homepage has to be deleted, including the reference to it. With a creation of a staff member it goes vice versa: There has to be a new homepage for this person, created automatically of the contents of the DB plus the embedding in the structure. Additionally there can be sent an e-mail with an introduction to the system and the request of a photo, if desired.

More generally: Creating and deleting requests to the DB require to a set of tasks, that have to be done beyond textual exchange. For this reason there will be a task list for each relation table, that consists of a list of the operations, the server has to do when a table row is created or deleted.

Figure 2: Automatic maintenance of the hypertext structure is realized with the meta database, that knows, where to make updates relating to updates in the DB.

The MDB is just an attempt to link formal data with text and does not claim to be a comprehensive method of maintenance, as this problem is rather a research topic with semantic an linguistic aspects.

Access control and security considerations

The applications shown in table 1 have to be used by the groups, they are provided for. Of course students must not have access to applications the chairs are using. For this reason there is a list that controls access of the users/groups. The chairs/ deans offices sender adress of their computers are stored here and the specific groups are only allowed access to their applications, i.e. access to URLs. In addition to this there is a password entry to be done before you enter the database section and it is valid, until you leave this section. If you quit Mosaic before leaving the application section a timeout will occur. After a reentry into the section there is another password query. For students the only DB application is the registration for exams. Here the password query is integrated in the form.

State of the project

Due to the three-part division of the information the static information exists on the server. This information comprises information for students and beginners.

Also there is a prototype of the administrating system with a yet reduced functionality. Only support for the chairs is provided yet, but the system and its data modell will be extended for its full functionality soon to enable the full set of applications.

The mail placer daemon is due runable and the chairs get informed then of the mail adress and the list of possible subjects.

Mosaic is running on all computer pools and there are two information kiosks (so-called Info Boxes) on the campus yet at some busy points for a quick information retrieveal, and three more are planned to cover the whole campus area.

The first computerized registration for exams will be in spring next year and then the last students, who have not been in contact with WWW, will. The Meta Database will be implemented when the relational Database has its full contents.



bmueller@rummelplatz.uni-mannheim.de