Figure 1: The information system embedded in its environment. The arrows indicate the direction of data flow.
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.
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.
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.
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.
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.