In diesem Beitrag wird mit dem LOTSEn ein operationeller Prototyp eines Datensuch- und -retrievalsystems beschrieben. Es ermöglicht die Eingabe von Beschreibungen zu Originaldaten, eine Suche von Originaldaten an Hand der Beschreibungen und das Retrieval sowie auch die Präsentation von Inhalten konkreter Datensätze. LOTSE ist vollständig über eine WWW-Oberfläche zu bedienen und auf Grund seines Rollenkonzeptes und der projektorientierten Organisation leicht erweiterbar.

Die Benutzung des Internets ist eine bekannte und weit verbreitete Methode, um auf entfernte digitale Dokumente zuzugreifen. Neben einzelnen Dokumenten sind auch Datenbanken über das Internet erreichbar. Nach der Erteilung entsprechender Zugriffsrechte können erfahrene Nutzer Abfragen an die Datenbank in der betreffenden Datenbankabfragesprache interaktiv oder innerhalb eigener Anwendungsprogramme vornehmen. Um auch weniger erfahrenen Nutzern einen Zugriff auf die Datenbank zu ermöglichen, wird meist eine komfortablere WWW-Schnittstelle in Form eines Browser-Formulars angeboten. In einzelne Formularfelder können Werte eingegeben werden, durch die sich vorformulierte Anfragen parametrisieren lassen.

Das Projekt TIDE (Tools for an Integrative View of Distributed Environmental Data) beschäftigt sich mit der Erstellung einer geeigneten WWW-Schnittstelle (LOTSE) für ausgewählte Datenbanken. Bisher ist ein einfach nutzbarer Prototyp auf der Basis herkömmlicher WWW-Techniken (CGI) entstanden. Zunächst wird in Abschnitt 2 und 3 die Einbettung dieses Prototypen in das Gesamtprojekt und sein genereller Aufbau geschildert. Daran schließt sich im Abschnitt 4 die Darstellung der Dateneingabe insbesondere der Metadaten an. Es folgen in Abschnitt 5 und 6 die Darstellung der zugrundeliegenden Datenhaltung und die Funktionsbeschreibung aus der Sicht eines Daten lesenden Nutzers (Lokalisierung von Daten und deren Präsentation). Weiterhin verlangt der Prototyp regelmäßigen Administrationsaufwand, der durch geeignete Werkzeuge gemildert werden kann. Diese Werkzeuge werden abschließend in Abschnitt 7 behandelt.

In Zusammenarbeit zwischen dem GKSS-Forschungszentrum und dem Fachbereich Informatik der Universität Hamburg wurden seit einigen Jahren benutzergerechte Zugangsmechanismen zu vorhandenen Datenbanken konzipiert und erstellt. Im Frühjahr 1997 konnte im Rahmen einer Hochschulkooperation zwischen GKSS und dem Fachbereich Informatik der Universität Hamburg das auf zwei Jahre konzipierte Projekt TIDE begonnen werden. Es soll den Zugriff nicht nur auf eine festgelegte Datenbank erlauben, sondern in einem Netz von heterogenen Datenquellen, wie verschiedenen Datenbanken, Datenbanksystemen und Filesystemen einsetzbar sein.

Bei der GKSS werden im Umweltforschungsbereich vielfältige Umweltdaten für Forschungszwecke gesammelt und vorgehalten. Im Institut für Gewässerphysik der GKSS sind z.B. Datensammlungen zum Bereich küstennaher Gewässer angelegt. Die Daten wurden innerhalb verschiedener auch externer Forschungsprojekte erhoben und lassen sich sehr unterschiedlichen Themengebieten zuordnen. So sind aus der Biologie verschiedene Zählungen und Kartierungen aufgenommen, ebenso Arbeiten mit chemischer Themenstellung und auch hydrographische Messungen zu Wasserbewegungen und Eigenschaften wie Temperatur, Salzgehalt und Trübungen.

Da die meisten Daten oder Datensammlungen in Projekten (zeitlich befristeten Arbeiten) zusammengestellt werden, sind sie auch in dieser Form zusammengefaßt. Ein Projekt ist somit die organisatorische und inhaltliche Einheit eines Datensatzes. Sie findet sich wieder in der Beschreibung der Daten, der Originatoren und der Zugriffsrechte, sowie auch als Ergebnis von Recherchen.

Projektdaten, die langfristig gesichert werden sollten, wurden in der Wattenmeerdatenbank WADABA aufgenommen. Diese Datenbank ist mit einem föderativ verteilten Datenhaltungskonzept (Dudler 1986) und Nutzerführungssystemen zum WATiS (Wattenmeerinformationssystem, Krasemann / Riethmüller 1994 und 1997) bereits vor Beginn des jetzt laufenden TIDE-Projekts ausgebaut worden.

Die Nutzerführungssysteme wurden in Zusammenarbeit zwischen der GKSS und dem Fachbereich Informatik der Universität Hamburg unter dem Titel LOTSE (Land Ocean Thematic Search Engine) konzipiert und realisiert (Leithäuser 1992a und 1992b), (Stille / Oswald 1993), (Willmann 1993), (Winter 1994), (Winter et al. 1995). Die Darstellungsformen verschiedenster Versionen reichen dabei von einfachen Terminalpräsentationen bis hin zu aufwendigen Kartendarstellungen, und die Recherchemöglichkeiten reichen von menügesteuerten, vorformulierten Anfragen bis hin zu freien SQL-Anfragen. Dabei wurde immer wieder der technischen Entwicklung und den Benutzeranforderungen Rechnung getragen.

Das Projekt TIDE soll nun neben der Datenbank auch weitere Datenbestände erschließen. Dabei sollen eine WWW-Anbindung der Datenbestände realisiert und ein Suchsystem mit Anfrageergebnissen übersichtlich präsentiert werden. Die Nutzung von WWW-Werkzeugen ist motiviert durch die Vielfalt an eingesetzten Rechnern, Betriebssystemen und der dezentralen Bearbeitung sowie den Möglichkeiten zur einfachen Aufbereitung und Verbreitung von Ergebnisdaten. In der ersten Projektphase wurden für die Nutzerführung herkömmliche WWW-Techniken wie CGI eingesetzt. In weiteren Projektphasen werden dann auch aufwendigere Techniken (Java / CORBA) betrachtet.

Das Gesamtsystem soll von verschiedenen Personengruppen nutzbar sein. Zunächst sollen die Mitarbeiter von Forschungsprojekten Einblick in die Arbeitsergebnisse ihrer Kollegen bekommen, soweit sich diese Ergebnisse in Datenbeständen wiederfinden lassen. Behörden, Forschungseinrichtungen und private Nutzer können sich einen Überblick über vorhandene Datenbestände verschaffen und auf Nachfrage bei den datenhaltenden Stellen auch Einsicht in die Originaldaten erhalten.

Eine ganz andere Art der Nutzung wird ein Administrator fordern. Ein Administrator sichert die Funktionsfähigkeit und die Konsistenz des Systems. Dazu bildet er sich sein eigenes Gedankenmodell des Systems. Dieses Bild ist wesentlich verschieden zu dem eines sich orientierenden (öffentlichen) Benutzers. Demzufolge ist für den Administrator eine eigene Systemkomponente bzw. spezielle Nutzungsschnittstelle vorzusehen.

Aufgrund der unterschiedlichen Nutzergruppen bietet sich bei der Realisierung des Gesamtsystems ein prototypisches Vorgehen an. Interessierte Nutzer erhalten zunächst Zugriff auf neue oder geänderte Systemfunktionalität und geben eine Beurteilung der Systemnutzung ab. Daraufhin können gezielt Verbesserungen erfolgen.

In der ersten in diesem Beitrag vorgestellten Projektphase des Projekts TIDE wurde der LOTSE/Web als voll funktionsfähiger Prototyp und in Fortsetzung der bisherigen LOTSE-Versionen realisiert. Vier Komponenten mit unterschiedlichen Funktionen arbeiten dabei zusammen. In Abb. 1 sind Suche, Retrieval, Dateneingabe und Administration als oberste Blöcke dargestellt. Die beiden ersten Komponenten, Suche und Retrieval, sind dabei für jeden Nutzer von direkter Bedeutung.

Abb. 1: Komponenten und Schichten des LOTSEn (dargestellt durch Blöcke)
sowie deren wesentliche Interaktionen und Informationsflüsse (Pfeile)

Die erste Komponente, die Datensuche, ist als Nutzerführung sowohl für gelegentliche als auch für erfahrene Benutzer des Systems realisiert. Dazu sind WWW-Schnittstellen zur Volltextsuche und zur Navigation vorhanden. Ergebnis einer erfolgreichen Suche ist die Beschreibung eines gefundenen Datenbestands an Hand der Metadaten des LOTSE-Systems, zusammengefaßt auf einer statischen HTML-Seite. Ein Teil der Beschreibung sind Referenzen zu den eigentlichen Daten (Originaldaten). Diese Referenzen können beispielsweise WWW-Links sein, die eine spezielle Präsentation der Originaldaten ermöglichen oder aber die Weiterleitung zu einem Retrieval- und Präsentationswerkzeug.

Das Retrieval und die Präsentation werden durch die zweite Komponente realisiert. Im Falle von WWW-Links folgt das weitere Verfahren der angegebenen WWW-Adresse. Für denjenigen Datenteil, der in der Datenbank WADABA abgelegt ist, wurde eine entsprechende WWW-Schnittstelle implementiert.

Die Suche, wie sie in der ersten Komponente realisiert ist, basiert auf Metainformationen aus dem LOTSE-System. Diese beschreibenden Daten werden über eine weitere, die Eingabekomponente LOTSIN, in die Datenbank gebracht. Der datenliefernde Nutzer wird unterstützt, seine Beschreibungen in einer speziellen Metadatenbasis abzulegen. Auch dies ist über eine WWW-Schnittstelle realisiert.

Mit der dritten Komponente, dem Administrationswerkzeug, werden die Metadaten in statischen Seiten zusammengefaßt, damit sie für die Suche aktuell zur Verfügung stehen. Dies hat zum einen den Vorteil einer leichten Leistungssteigerung, weil die navigierenden Informationen nicht für jede Anfrage neu zusammengestellt werden müssen, zum anderen aber ist damit eine einfache und elegante Integration des LOTSEn in weltweite Suchsysteme gelungen.

Die vierte Komponente sorgt für den Transfer der Metainformationen aus der zugrunde liegenden Metadatenbasis in die vermittelnde Ebene, bei der jetzigen Realisierung sind das die statischen Seiten mit den Metadaten sowie die Daten der eingesetzten Suchmaschine. In Abb. 1 wird für LOTSE diese Teilung in drei Schichten zwischen Datenbasis einerseits und den Nutzern andererseits sowie einer vermittelnden Ebene dazwischen deutlich.

Die Dateneingabe im Rahmen des LOTSEn geschieht mit Hilfe des Programmpaketes LOTSIN. Es muß zunächst geklärt werden, welche Daten und Datensammlungen durch Metadaten beschrieben werden sollen. Ein solcher Satz von Informationen wird einfacherweise zu einer Einheit zusammengefaßt, die im folgenden Projekt genannt wird. Ein Projekt ist die wesentliche Struktureinheit im gesamten LOTSE und LOTSIN-System. Diese Projektorientierung ist aus dem Wattenmeerinformationssystem WATiS übernommen worden und wurde in dem Zusammenhang bereits eingehend diskutiert (Krasemann / Riethmüller 1994, 1997 und Krasemann et al. 1991).

Jede Information bezieht sich immer auf ein Projekt. Die Beschreibung eines solchen Projekts wird immer gleich gehalten. Die Inhalte sind dagegen flexibel und werden den jeweiligen Anforderungen angepaßt. Damit ist gewährleistet, daß auch sich verändernde Anforderungen immer abgebildet und dargestellt werden können. Dies kann in einer dem jeweiligen Projekt hochgradig angepaßten Struktur geschehen, was die Akzeptanz beim Daten anbietenden Projekt steigert. Als Nachteil steht die mit wachsender Datenfülle auch steigende Komplexität der Gesamtheit aller Daten gegenüber. Nutzerführungen wie LOTSE können dies kompensieren. Es muß dann festgelegt werden, für welche Aufgaben und Zielstellung Daten vermittelt bzw. zur Verfügung gestellt werden sollen. Den Rahmen dafür bildet immer das Projekt als Einheit, die Daten einer Aktivität zusammenfaßt.

Zur Illustration sei hier ein Beispiel aufgeführt: Das Projekt mit dem Akronym PROMISE steht für "PRe Operational Modelling In the Seas of Europe". Dies ist auch der Kurztitel des Projekts. Das Projekt strukturiert seine Daten völlig selbständig und im wesentlichen auch frei von festen Vorgaben. Lediglich die beschreibenden Daten, die sogenannten Metadaten, werden in einem für alle Projekte gemeinsamen Rahmenschema abgelegt. Dies geschieht mit Unterstützung von Web-Eingabe-Seiten. Die Metadaten (Beschreibung der Ziele, zeitlicher und örtlicher Rahmen) beziehen sich immer auf das gesamte Projekt.

Es können eine Reihe von Informationen aufgenommen und für spätere Suchen verwendet werden. Das LOTSE/LOTSIN-System ist so konzipiert, daß keine Information formal obligatorisch ist mit Ausnahme des Projektkürzels. Damit können auch unvollständige oder Teilinformationen aufgenommen, später ergänzt oder auch nur in ihren Teilen zur Suche verwendet werden. Dies ergibt eine hohe Toleranz und Flexibilität des Systems für ungewöhnliche Eingaben. Die möglichen Angaben werden im einzelnen wie folgt beschrieben.

Jede Datensammlung, jedes Projekt wird identifiziert durch sein Projektkürzel, ein eindeutiges maximal 8 Zeichen lange Abkürzung. Dies wird auch als Nutzerkennung des Projektverantwortlichen verwendet. Er hat damit für sein Projekt die Autorisierung, beschreibende Informationen neu aufzunehmen oder zu verändern. Dieses Kürzel wird in Übereinkunft mit dem LOTSE-Team gewählt und von diesem auch eingerichtet. Diese Nutzerkennung mit Paßwort ist einzugeben bevor man weitere Eintragungen machen kann.

Neben dem Kürzel ist der Projekttitel wichtig, der in einer kurzen Überschrift von maximal 80 Zeichen das Projekt charakterisiert. Der folgende Abstrakt kann in einem Fließtext von bis zu 2000 Zeichen das Projekt kurz erläutern. Hierbei wird der Text als HTML (HyperText Markup Language) interpretiert. Es ist also möglich, Referenzen auf weitere Quellen oder andere Strukturierungsmerkmale einzubauen. Allerdings wird diese Zusatzinformation durch HTML-Tags in der Projektbeschreibung bei einer Weitergabe an andere Metainformationssysteme wie z.B. dem Global Change Master Directory nicht beachtet. Beide Texte sind nicht erzwungen, sondern die Eingabe ist optional, sollte aber für ein Projekt immer abgelegt werden, damit es in seinen wesentlichen Zügen charakterisiert ist und von Dritten auch so verstanden werden kann.

Für ein Projekt kann ein zeitlicher und örtlicher Rahmen angegeben werden, der das ganze Projektgebiet bzw. den ganzen relevanten Projektzeitraum umfassen sollte. Der zeitliche Rahmen enthält dabei das Anfangsdatum, für das die ersten gültigen Daten zur Verfügung stehen, und das Enddatum, ab dem es keine Daten mehr gibt. Dies ist nicht notwendigerweise der Bearbeitungszeitraum des Projekts, sondern die Zeitangaben sollen sich auf die Daten beziehen. Ebenso kann ein örtlicher Rahmen angegeben werden in Form von geographischen Koordinaten in Grad, Minuten und ggf. Sekunden: Westliche und östliche sowie nördliche und südliche Grenze der Projektdaten, wobei Längen westlich Greenwich und Breiten südlich des Äquators negativ anzugeben sind.

Darstellungen und Suchen im LOTSEn sind über Kartendarstellungen realisiert, die Eingabe der Werte geschieht in der aktuellen Version des LOTSEn nur über Koordinateneingaben. Auch diese Angaben von Metainformation sind optional und nicht zwingend. Sie erlauben aber eine gezieltere Suche. Dabei können Projekte, die keine Angaben gemacht haben, bei einer örtlich oder zeitlich spezifischen Suche nicht gefunden werden, sondern nur bei einer Suche ohne diese Kriterien.

Die Adressen der Ansprechpartner sind in einem gemeinsamen Adressenteil organisiert. Alle Adressen, die über LOTSE und LOTSIN verwaltet werden, setzen sich zusammen aus einem Institutsteil, dem Ort, Straße, Land, Haupttelefonnummern u.ä. zugeordnet sind und einem Personenteil, der Namen, Email und persönliche Telefonnummern enthält. Eine Kombination aus Personenteil und Institutsteil ergibt eine Adresse. So können mehrere Personen eines Instituts eine konsistente, aber leicht abweichende Adresse haben oder auch eine Person mehrere Adressen haben.

Zu einer Adresse wird ferner vermerkt, unter welcher Nutzerkennung sie eingetragen wurde. Nur dieser Nutzer kann sie auch ändern oder löschen. Damit Dritte diese Adresse lesen können, muß der Erzeuger die Adresse auch öffentlich machen. Erst dann kann sie in einem Projekt als Adresse eines Ansprechpartners verwendet werden. Nur öffentliche Adressen können im Projekt zugeordnet werden. Die Zuordnung einer öffentlichen Adresse als Ansprechpartner zu einem Projekt ist dann unabhängig davon, wer sie eingetragen hat. Bei der Zuordnung kann man aus allen öffentlichen Adressen auswählen und sie dem derzeitig aktuellen Projekt zuordnen.

Schlagworte und Schlüsselworte sind von entscheidender Bedeutung, um ein Projekt bei einer Suche als relevant und interessant zu identifizieren. Für LOTSIN sind mehrere Schlagwortsysteme parallel vorgesehen, wie der interne aus dem WATiS übernommene Schlagwortbaum (s. Abschnitt 7) oder der Schlagwortkatalog des Global Change Master Directory (GCMD). In der jetzigen Version ist eine freie Schlagworteingabe realisiert. Beliebige Schlagworte können eingegeben und damit bei späteren Suchen als Erkennungsmerkmal benutzt werden. Einige spezielle Schlagworte kennzeichnen besondere Zuordnungen. So erkennt LOTSE bei Suchen nach GKSS-beteiligten Projekten diesen Sachverhalt an dem Vorhandensein des Schlagwortes gkss-g.

Die Integration weiterer Schlagwortsysteme wie z.B. den CDS (Catalogue of Data Sources der EEA) bzw. UDK (Umweltdatenkatalog deutschsprachiger Länder) ist für Ende 1998 vorgesehen. Dabei wird nur eine alternative parallele Nutzung implementiert. Eine weitere Vernetzung wie im Beitrag (Nikolai / Kramer 1998) beschrieben, ist für weitere Phasen des TIDE-Projekts denkbar.

Die beschreibenden Daten oder Metadaten sind ein Hilfsmittel, um die interessierenden Daten aufzufinden und zu identifizieren. Die Metadaten können auch als wesentlich konkretere Form eine Beschreibung und Erläuterung der eigentlichen Daten mit umfassen. Entscheidend ist der weitere Verweis zu den eigentlichen Daten. Dies kann ein Quellenhinweis sein, z.B. auf eine vorhandene Veröffentlichung, es kann auch der Verweis auf eine Datensammlung bei einer bestimmten Institution sein.

Besonders hilfreich ist es, wenn dieser Verweis nicht nur auf eine Adresse oder Telefonnummer sondern direkt auf einen Rechner im Netz hinweist. Ein solcher WWW-Link erlaubt, die angegebene Referenz sofort zu befragen. Es eröffnet damit auch die Möglichkeit, die Quelle mit den Originaldaten sofort weiter zu hinterfragen. Hier können die Daten leichter auf dem aktuellen Stand gehalten werden, als dies einer zentralen Stelle möglich wäre. Die Originaldaten können als einfache tabellarische Textdateien abgelegt sein. Es kann sich auch um HTML-Dokumente handeln, die speziell an das WWW angepaßt sind. Es können auch aufwendigere angepaßte Systeme sein, die z.B. dynamisch einen Satz gewünschter Daten beschaffen und präsentieren.

Die am besten strukturierte Form der Datenorganisation ist eine Datenbank, wobei sich in der Praxis relationale Systeme bewährt haben. Die Anbindung einer relationalen Datenbank an ein Suchsystem und die Erweiterung zu einem Retrievalsystem erfordert einige Anpassungsarbeit. Es wird aber selten dieselbe Funktionalität bei gleichzeitiger Vereinfachung der Bedienung erreichbar sein. Auch im LOTSE erlaubt das Retrieval einfach über wenige Klicks nur die Auswahl einzelner, in der Datenbank vorhandener Tabellen oder Views. Die Ausgabe kann auch auf wenige Zeilen beschränkt werden. Die vollen Möglichkeiten der relationen Datenbank mit dem integrierten SQL sind aber nur geschulten Nutzern offen, die auch die SQL-Syntax beherrschen.

Der Verweis zu den Originaldaten, der mit LOTSIN eingetragen wird, ist ein Text, der entweder als Schlüsselwort eine bekannte angebundene Datenbank enthält, zur Zeit ist dies nur die WADABA des WATiS. Auch enthalten sind in der WADABA die Daten des ForschungsverbundProjekts GOAP (Greifswalder Bodden und Oderästuar Austauschprozesse) die vormals in einem mit WATiS identischen System, dem ODiS, repräsentiert durch eine Teildatenbank ODABA, abgelegt waren. Wenn der Verweis auf eine andere Quelle zeigen soll, wird lediglich die URL eingetragen. Diese Angabe kann durch einen Kommentar ergänzt werden, der die Bedeutung der URL erläutert.

Die Einbringung von Daten in individuelle Datenbankstrukturen erfordert ebenso geschulte Kenntnisse der Möglichkeiten einer relationalen Datenbank. Dies in LOTSIN weiter zu unterstützen ist Ziel des Projekts. Es stehen zur Zeit die Standardwerkzeuge des WADABA Datenbankmanagementsystems zur Verfügung.

Bei der Eingabe der beschriebenen Metadaten durch LOTSIN ist zu bedenken, daß alle Eingaben einerseits direkt in der Datenbank mit Hilfe von dynamisch erzeugten Web-Formularen durchgeführt werden. Auf der anderen Seite verwendet der LOTSE aber für die Recherche statische Seiten, die jeweils durch spezielle Programme der Administration auf den neuesten Stand gebracht werden. Diese zunächst umständlich erscheinende Funktionalität hat den Vorteil, daß fertig erhältliche Suchsysteme integriert werden können (Abschnitt 5.2). Ein weiterer und entscheidender Gewinn ist, daß durch statische Seiten viele, bereits weltweit agierende Suchmaschinen mit in das System eingebunden sind. So ergibt z.B. eine Suche bei AltaVista nach dem Schlagwort Schadstoffkartierung neben einigen anderen Treffern auch die statische Seite mit den Metainformationen, d.h. den Beschreibungen des Projekts SCHADS, einer Schadstoffkartierung des deutschen Wattenmeeres. Diese Beschreibungsseite ist Bestandteil des LOTSEn und wurde mit LOTSIN erstellt.

Jede Änderung, die mit LOTSIN in der Datenbank durchgeführt wird, muß, bevor sie für die Recherche wirksam werden kann, in die statische Seite überführt werden. Jeder Eintrag wird somit nach zwei Stufen wirksam (erstens Sicherung in der Datenbank, zweitens Übertragung in die statische LOTSE-Seite). Die Reihenfolge der einzelnen Einträge, wie sie im vorigen Abschnitt beschrieben wurden, ist dabei nicht von Belang. Es empfiehlt sich lediglich aus inhaltlichen Gründen mit der Projektbeschreibung zu beginnen und anschließend Adressen, örtliche und zeitliche Rahmen, Schlagworte, sowie den Ort der Originaldaten einzutragen. Es muß in jedem Fall abschließend die statische Seite der Metainformation erneuert werden oder bei einem Neueintrag bzw. einer Änderung der Navigationsschlagworte auch die entsprechenden statischen Seiten erneuert werden. Die Administrationswerkzeuge sind im Abschnitt 7 eingehender beschrieben.

Um sich einen Überblick über die vorhandenen Datenbestände der einzelnen Forschungsprojekte zu verschaffen, stehen dem Endbenutzer Suchanfragen und Navigationsmöglichkeiten zur Verfügung. Unter Suche verstehen wir den Abgleich der Metadaten mit den spezifizierten Kriterien einer Anfrage. Suchanfragen können die gewünschten Datenobjekte sehr genau eingrenzen, setzen aber ein Mindestmaß an Überblick über den verfügbaren Datenbestand voraus.

Abb. 2: Lokalisierung von Datenbeständen

Demgegenüber bietet die Navigation einem unerfahrenen Nutzer die Möglichkeit, sich den Datenbestand Schritt für Schritt zu erschließen. Unter Navigation verstehen wir die geleitete Bewegung von einem Knoten in einem Navigationsgraphen zu einem benachbarten Knoten, wobei jeder Knoten die Beschreibung eines Datenobjekts oder Metadatums repräsentiert. Eine Schlagwortsammlung ist beispielsweise eine übliche Struktur, die zu Navigationszwecken benutzt wird. Für die LOTSE-Nutzerführung werden verschiedene Schlagwortsammlungen herangezogen und zusammengeführt. Sie stehen in verschiedenen Ausführungen zur Verfügung (mehr dazu im folgenden Abschnitt 5.1). Weiterhin existieren alphabetisch geordnete Listen, die den direkten Zugriff auf Metadaten erlauben. Um die Listen sinnvoll einsetzen zu können, muß dem Nutzer jedoch der Name des zugehörigen Forschungsprojekts bekannt sein.

Die LOTSE-Nutzerführung arbeitet in den Bereichen Navigation und Metadaten mit automatisch generierten, statischen HTML-Seiten. Um diese Seiten zu generieren, wurden einige beschreibende Daten aus der eingesetzten Datenbank extrahiert und durch verschiedene Skripte nach HTML konvertiert. Dieser Abschnitt beschreibt den Inhalt und die Hyperlink-Strukturen für diese HTML-Seiten. Die notwendigen Übersetzungsroutinen sind im Abschnitt 7 beschrieben.

Der Einsatz von statischen Seiten ist in den Bereichen Navigation und Metadaten möglich, da die aufbereiteten Seiten nur wenig Speicherplatz im Vergleich zu den vorhandenen Originaldaten beanspruchen und für diese Informationen nur selten Änderungen auftreten. Statische Seiten liefern einen einfachen Einstiegspunkt in die Volltextrecherche, da sie mit Hilfe der eingesetzten Suchmaschine leicht zu indizieren sind. Deshalb werden diese beschreibenden Informationen in vorbereiteter Form gehalten und ohne zusätzlichen Berechnungsaufwand bereitgestellt. Im Falle mehrerer gleichzeitiger Anfragen stellen statische Seiten gegenüber dynamischen, per CGI-generierten Seiten außerdem einen Lastvorteil dar. Da die statischen Seiten jedoch Kopien von Datenbankinhalten sind, müssen die Seiten bei Änderungen in der Datenbank nachgeführt werden. Um den permanenten Administrationsaufwand leichter bewältigen zu können, existieren einige Administrationswerkzeuge (Abschnitt 7), die die notwendigen Übersetzungsroutinen erneut anstoßen.

Für die themenorientierte, strukturierte Navigation per LOTSE-Nutzerführung wird die Schlagwortsammlung Menübaum herangezogen. Dieser Menübaum setzt sich zusammen aus GKSS-internen Strukturen bzgl. Themen, Orten und Projekten. Hinzu kommt noch der Strukturierungsvorschlag aus dem Global Change Master Directory (GCMD) der NASA für Parameter. Die GCMD-Struktur und der ursprüngliche Menübaum sind zu einem zentralen Baum zusammengeführt. Dazu wurden die GCMD-Einträge in diejenigen Tabellen eingefügt, die den ursprünglichen Menübaum halten. Änderungen an der Struktur (Löschen, Verschieben) sollten weder beim Menübaum noch bei der GCMD-Struktur vorkommen, da entsprechende Knoten bereits von Anwendungen benutzt werden könnten, denen durch solche Änderungen die Grundlage entzogen würde.

Der ursprüngliche, GKSS-interne Teil des zentralen Menübaums umfaßt ca. 150 Einträge, der GCMD-Teil ca. 4300 Einträge. Der kleinere Teil liegt in einer kompakten Form vor, in der alle 150 Knoten auf einer HTML-Seite zu finden sind. Auf dieser Seite sind die Positionen der einzelnen Knoten durchnumeriert und als HTML-Anker vorhanden, so daß auch innerhalb der Seite gezielt Knoten aufgerufen werden können. Neben der kompakten Version findet sich auch eine aufgeteilte Version aller ca. 4500 Einträge. Je Eintrag existiert eine eigene Seite, die Verweise auf übergeordnete, untergeordnete und Nachbarknoten sowie auf die zugeordneten Projetkte enthält. Da ein Forschungsprojekt mehrere Verschlagwortungen aufweisen kann, ist je Projekt eine eigene Seite mit Verweisen zu den eingetragenen Verschlagwortungen vorhanden.

Neue Forschungsprojekte sind häufig noch gar nicht verschlagwortet. Sie können mit Navigationswerkzeugen, die auf Schlagwortsammlungen aufbauen, daher nicht erreicht werden. Deshalb sind alle Projekte noch einmal alphabetisch auf einer eigenen HTML-Seite aufgelistet. Zu jedem Projekt kann eine Metadatenübersicht und die vorgenommene (evtl. leere) Verschlagwortung erreicht werden. Die eigentlichen Metadatenseiten enthalten die im Abschnitt 4 aufgelisteten beschreibenden Daten in grafisch aufbreiteter Form. Diese Seiten stellen den Übergang von der Lokalisierung zur Präsentation von Originaldaten her.

Suchanfragen sind natürlicherweise dynamisch. Die Suche bezieht sich immer auf den aktuellen Stand der vorhandenen Informationen. Deshalb bietet sich hier der Einsatz von CGI-Lösungen an. Zur Abarbeitung von Suchanfragen über Dokumente stehen schon ausgereifte Produkte zur Verfügung. Zur Volltextsuche in den Metadatenseiten setzt der LOTSE das Harvest-System ein, das konfigurierbare Komponenten aus den Bereichen Sammeln (Gathering), Auffinden (Brokerage), Vervielfältigung (Replication) und Zwischenspeicherung (Caching) enthält. Da nur eine zentrale Anlaufstelle für Suchanfragen vorgesehen ist, wird die Vervielfältigung nicht eingesetzt. Auch die Zwischenspeicherung wird aufgrund des z.Zt. geringen Anfragevolumens nicht durchgeführt. Diese Komponenten lassen sich jedoch bei Bedarf ohne Änderung der anderen Komponenten hinzufügen.

Abb. 3: Komponenten des Harvest-Systems
(hell: verwendet, dunkel: ungenutzt)

Das Einsammeln von vorhandenen Dokumenten kann im Prinzip vollautomatisch geschehen, indem eine Startseite und eine Verweistiefe angegeben werden, woraufhin der zugehörige Gatherer-Prozeß die Referenzen der Startseite bis zur Verweistiefe hin weiterverfolgt und alle besuchten Dokumente aufbereitet. Da diese Art des Einsammelns jedoch einen Depth-First-Algorithmus verwendet, die Gesamtanzahl der Dokumente in der Regel begrenzt ist und die notwendigen Verweise nicht immer am Anfang einer Seite stehen, liefert dieses Verfahren meist nicht alle gewünschten Dokumente. Deshalb wird dem Gatherer-Prozeß eine Liste aller zu bearbeitenden Dokumente vorgelegt, die aus einer Verzeichnisauflistung leicht zu erzeugen ist. Ein spezieller Filter erkennt den Dokumenttyp HTML und extrahiert aus dem Dokument alle Informationseinheiten.

Dieser Extrakt wird einem Broker-Prozeß übermittelt, der die Informationseinheiten des Dokuments indiziert und so eine effiziente Volltextsuche ermöglicht. Als WWW-Frontend dient hier wieder ein Formular mit dahinterliegendem CGI-Skript. Das Skript läßt sich so konfigurieren, daß die Antworten dem üblichen LOTSE-Layout entsprechen. Als Ergebnis liefert eine Suchanfrage mit diesem Formular eine Liste mit URLs zu denjenigen Metadatenseiten, die den vorgegebenen Suchbegriff enthalten. Im Suchbegriff sind Wildcards und logische Ausdrücke erlaubt. Dieser Suchmechanismus beschränkt sich auf reine Textvergleiche. Numerische Vergleiche lassen sich damit nicht durchführen. Auch Suchanfragen mit Synonymen oder Begriffen mit ähnlichem Wortstamm lassen sich nur auf Umwegen beschreiben.

Die üblichen Eingaben im WWW-Browser wie z.B. Mausklicks auf Referenzen und Einträge in Formularfelder sind nicht interaktiv. Die Anwendung kann die Eingaben erst überprüfen, nachdem sie an einen Server abgeschickt und dort bearbeitet wurden. Abhilfe können hier Browser-seitige Skript- oder Programmiersprachen leisten. Dabei wird ausführbarer Programmcode vom Browser mit der Seite geladen und auch im Browser ausgeführt. Die Programmiersprache Java ist ein Beispiel für eine Erweiterung, die von einigen Browsern bereits unterstützt wird. Sie bietet eine Ausführungsumgebung, die die interaktive Ein- und Ausgabe ermöglicht.

Der LOTSE kann diese Interaktionsmöglichkeiten nutzen, um beispielsweise eine einfache geographische Suche zu ermöglichen. Als Hintergrundbild dient dabei ein Satellitenfoto des deutschen Wattenmeeres. Über dem Bild kann ein Rechteck aufgezogen werden, das eine geographische Suchanfrage parametrisiert. Auf Knopfdruck wird eine Datenbankanfrage generiert und ausgeführt, die alle Projekte innerhalb des angegebenen Rechtecks ermittelt und als Liste von Befehlsknöpfen ausgibt. Mit jedem Befehlsknopf wird dann zur Metadatenseite des entsprechenden Projekts gesprungen. Damit lassen sich auch die herkömmlichen statischen Seiten und CGI-Techniken in eine Gesamtanwendung integrieren.

Die Originaldaten vieler Projekte sind in der Wattenmeerdatenbank WADABA abgelegt. Sie werden über eine eigene WWW-Schnittstelle auf CGI-Basis präsentiert. Da die Projektkürzel auch als Datenbankbenutzer eingerichtet sind, können die vorhandenen Tabellen eines ausgewählten Projekts unmittelbar per Datenbankanfrage ermittelt werden. Nach der Auswahl einer Tabelle wird ein gewünschter Ausschnitt per Skript als HTML-Tabelle dargestellt.

Abb. 4: Präsentation von WADABA-Inhalten

Der Zugang zu den Originaldaten unterliegt der Zugriffskontrolle. Nur über die korrekte Eingabe von Benutzernamen und Paßwort lassen sich diese Informationen per WWW auslesen. Damit die Zugangskennungen nicht ungeschützt über das Internet übertragen werden, kommt das von vielen WWW-Browsern bereits implementierte HTTPS-Protokoll zur verschlüsselten Datenübertragung zum Einsatz, das auf einer sicheren Übertragungschicht (Secure Socket Layer, SSL) basiert. Dabei identifizieren sich Browser und Server gegenseitig und tauschen einen Sitzungsschlüssel aus, der im weiteren Verlauf der Übertragung zum Ver- und Entschlüsseln der nachfolgenden Daten dient.

Abb. 5: Geschützter Zugang zu Originaldaten per HTTPS / CGI

Für den LOTSEn wurde ein spezielles SSL-Add-On des eingesetzten WWW-Servers benutzt. Damit kann ein HTPPS-Server instantiiert werden. An diesen Server wenden sich nun alle Anfragen, die per Paßwort geschützt sind. Damit nicht für jede Seite die notwendige Zugangskennung erneut übertragen werden muß, implementiert der LOTSE ein Sitzungskonzept auf Anwendungsebene. Die eingegebenen Kennungen behalten für einen bestimmten Zeitraum ihre Gültigkeit, und der Browser erhält während dieser Gültigkeitsdauer die Ergebnisse der Anfragen, sonst wird die Zugangskennung erneut angefordert. Dazu wertet ein CGI-Skript die HTTPS-Anfragen mit der Zugangskennung aus und legt sie in einer gesicherten Datei ab. Originaldaten können nun über HTTP-Anfragen durch weitere CGI-Skripte abgearbeitet werden, da diese Skripte die abgelegte Zugangskennung erkennen.

Die Lokalisierung von Daten erfolgt mit Hilfe von statischen HTML-Seiten, die nicht mehr dem aktuellen Stand in der darunterliegenden Datenbank entsprechen könnten. Deshalb wurde ein Administrationswerkzeug auf CGI-Basis geschaffen, mit dem sich verschiedene Skripte zum erneuten Aufbau der statischen Seiten anstoßen lassen. Dabei sind unterschiedliche Arten von Seiten (Seiten im Menübaum, Indices, Metadaten) und unterschiedliche Schritte der Erzeugung (DB-Anfrage, Lesen aus Datei) einstellbar.

Um die Navigationsseiten zu erzeugen, werden aus der Datenbank Informationen über die Struktur des Menübaums, über die vorhandenen Projekte sowie über die Beziehungen zwischen Projekten und Knoten im Menübaum ausgelesen. Diese Informationen werden in Dateien zwischengespeichert, um ein neues Seitenlayout auch ohne erneute Datenbankabfrage aufbauen zu können. In einem Perl-Skript wird die Baumstruktur als Datenstruktur nachgebildet, und die Projekte werden an den entsprechenden Knoten eingefügt. Diesen Datenverbund arbeiten dann je nach gewünschter Ausgabe verschiedene Übersetzerroutinen rekursiv ab und erzeugen entsprechende HTML-Seiten. Da die Knoten des Menübaums durchnumeriert sind, dient die Knotennummer auch als Ankerpunkt für Referenzen zwischen den einzelnen Seiten bzw. innerhalb einer komplexen Seite.

Abb. 6: Knoten im Menübaum: vom Datenbankinhalt zur HTML-Seite

Für die Metadatenseiten ist der Aufbau und die Zwischenspeicherung komplexerer Datenstrukturen nicht notwendig. Es existiert ein Grundgerüst, in das je Metadatenseite Werte eingefügt werden für den Abstract, die zeitliche und räumliche Gültigkeit sowie für Adreßinformationen. Diese Informationen sind für jedes Projekt direkt aus der Datenbank abfragbar.

Da Metadaten jederzeit von ihren Autoren erweitert oder geändert werden können, spiegelt eine statische Seite nicht unbedingt den aktuellen Stand der Datenbank wider. Deshalb gibt es die Möglichkeit, den Inhalt einer Metadatenseite per CGI-Skript mit dem aktuellen Stand ausfüllen zu lassen. Ein Befehlsknopf dazu ist in jeder statischen Metadatenseite vorhanden.

Die Suchmaschine indiziert nur die Inhalte der statischen Metadatenseiten. Ändern sich diese, so sollte auch ein erneuter Lauf zum Einsammeln und Aufbereiten der Seiten erfolgen. Auch dazu wurde ein Administrationswerkzeug auf CGI-Basis erstellt. Es stößt den im Abschnitt 5.2 beschriebenen Gatherer-Prozeß an. Dessen Ergebnis wird regelmäßig vom Broker-Prozeß abgefragt. Zusätztlich existiert noch ein Werkzeug, das mit der Suchmaschine geliefert wird und u.a. Ein- und Austräge sowie das unmittelbare Einlesen der Gatherer-Ergbnisse in den Broker ermöglicht.

Update-Probleme kommen in heterogenen Systemen häufig vor. Dabei lassen sich die Änderungen an Datenbankinhalten als Ereignisse auffassen, und die hier verwendeten Seitenarten lassen sich regelbasiert beschreiben. Somit ist die Anwendung von Event-Condition-Action-Regeln eine Möglichkeit, um Update-Zyklen zu steuern. Der in (Koschel / Kramer 1998) beschriebene Mechanismus zur Konfiguration der Ereigniserkennung bietet auch für eine zukünftige Version des LOTSEn Einsatzmöglichkeiten.

Mit dem ersten Prototypen des LOTSE/LOTSIN-Systems liegt ein WWW-Werkzeug vor, das auf einfache Weise von verschiedenen Nutzergruppen anwendbar ist. Es stellt für die Nutzung grundlegender Funktionalität keine besonderen Anforderungen an die Ausstattung der Plattform eines Endbenutzers. Die gängigen Browser mit grafischer Oberfläche sind dafür ausreichend. Vorhandene Datenbestände lassen sich einfach lokalisieren. Der in der Wattenmeerdatenbank WADABA vorhandene Teil des Datenbestands kann direkt eingesehen werden, wobei ein Zugriffsschutzkonzept realisiert wurde. Dasselbe Konzept wird auch für die Eingabe und Änderung von Metadaten angewandt.

Bei der Realisierung kamen verbreitete Datenbank- und CGI-Techniken zum Einsatz, womit sich die vorliegende Version zügig entwickeln ließ. Das System ist direkt auf andere Datenbestände erweiterbar, wenn diese per Hyperlink erreichbar sind. Durch die Nutzung Client-seitiger Erweiterungen wie z.B. die Integration einer virtuellen Maschine für die Programmiersprache Java lassen sich wesentlich flexiblere, komfortablere, interaktive Ein- und Ausgabemethoden entwickeln. Bereits realisiert wurde hier eine einfache geographische Suchanfrage. Die Ausgabe erfolgt in Kartenform, wie sie auch in (Toussaint 1998) vorgesehen ist. In diesem Bereich werden bis zum Ende des Projekts noch wesentliche Implementierungen vorgenommen, und die Nutzungschnittstelle wird an die üblichen Interaktionsmöglichkeiten (Listen, Menüs etc.) angepaßt.

Der LOTSE verwendet zur Speicherung von Metadaten eine zentrale Datenbank. Damit sind die Daten liefernden Benutzer auf die spezielle LOTSIN-Schnittstelle angewiesen, oder sie müssen einen direkten Zugang zur Datenbank besitzen. Sollen andere bestehende Systeme integriert werden, so bietet sich eine dezentrale Speicherung der Metadaten an. Dann können nämlich zusätzliche, speziell für einen Datenbestand sinnvolle Metadaten angegeben und ggf. auch automatisch aus Originaldaten ermittelt werden. Einen wesentlichen Schritt in diese Richtung werden die nächsten Projektphasen vollziehen, wenn abstrakte Schnittstellen für Datenbestände beschrieben sind. Zur Umsetzung wird dann moderne, verteilte Systemtechnik (CORBA) herangezogen und in einer dreistufigen Architektur umgesetzt werden (Gehlsen et al. 1998). Es ist zu erwarten, daß auch andere Umweltinformationssysteme auf die CORBA-Technologie setzen, wie sich bereits in (Freitag 1998) und (Koschel / Kramer 1998) andeutet, und damit der Weg hin zu flexiblen und interoperablen Systemen geebnet wird.