PRISMA - Picture Retrieval and Information System of Modern Arts




1. Die Entwicklung des Internet

1.1. Ein Überblick

Vor mehr als 25 Jahren entstand im Auftrag des Verteidigungsministeriums der Vereinigten Staaten von Amerika der Vorläufer des heutigen Internet, das ARPA-Netzwerk, im Rahmen einer militärischen Forschungsstudie. Ziel der damaligen Forschungen war es, ein Kommunikationssystem unter Computern zu erstellen, das trotz partiellen Ausfalls durch Feindeinwirkung seine Funktionalität behalten konnte. Die hierfür verwendeten Verbindungswege wurden wenig spezifiziert. Wichtiger war, daß alle angeschlossenen Computer miteinander als Sender und Empfänger kommunizieren konnten. Zum Versenden einer Nachricht wurden Daten in ein Internet Protocol (IP) verpackt und mit der Adresse des Zielrechners versehen. Der Zielrechner wiederum bestätigte den richtigen Empfang der Sendung. Die hier entwickelte IP-Kommunikationssoftware setzte sich später als Standard der Kommunikation zwischen Computern aller Plattformen auch im zivilen Bereich und so auch auf dem Internet durch [8].

Die Ausstattung mit IP-Software auf allen Computerplattformen kam vor allem öffentlichen Einrichtungen und Universitäten zupaß. Gerade letztere konnten innerhalb ihrer Institute nicht nur eine Computerplattform beschaffen, ihre Maschinen sollten aber trotzdem untereinander kommunizieren können. Mit dem Aufkommen von Ethernet local area networks (LAN) und IP-fähigen Workstations entstanden innerhalb von Universitäten Netzwerke von Computern, die über IP miteinander verbunden waren. Folgerichtig wollten die Universitäten dann an das ARPA-Netzwerk angeschlossen werden, um von dessen Diensten Gebrauch zu machen und um so die Netzwerke verschiedener Universitäten miteinander zu verbinden.

Die darauf von der US-Regierung gebildeten Supercomputerzentren der National Science Foundation (NSF) betrieben untereinander ein leistungsfähiges Netz für wissenschaftliche Zwecke. Da das ARPA-Netz aus Verwaltungsgründen hierfür nicht genutzt werden sollte, wurden diese Zentren untereinander mit eigenen Leitungen vernetzt. Gleichzeitig stellten viele Bildungseinrichtungen Leitungsverbindungen zu ihren jeweiligen Nachbareinrichtungen her und so bildete sich nach und nach ein Netz, dessen Einzelstationen in der Lage waren, Abfragen von Nachbarn an den nächsten weiterzugeben bis zum Bestimmungsort und umgekehrt. Solche lokalen Netze wurden dann an einer Stelle mit einem der Supercomputerzentren verbunden. Netzwerke dieser Art entstanden weltweit und verbanden sich zum Internet [8].

Gegen Ende des Jahres 1996 ist das Internet beziehungsweise sein populärster Dienst, das World Wide Web (WWW) nicht mehr nur Kommunikationsmittel im universitären Bereich. Das ursprünglich militärisch und anschließend als Wissenschaftsnetz zum Datenaustausch zwischen Universitäten genutzte Netzwerk gewinnt trotz hoher Kosten für die Nutzung der Übertragungsleitungen zunehmend auch für kommerzielle und private Anwender an Bedeutung. Vor allem die Nutzung als Werbeplattform in unterschiedlichen Bereichen steigerte sich im vergangenen Jahr enorm. In den bisher für Werbung genutzten Medien (Druckmedien, Rundfunk und Fernsehen) tauchen vermehrt WWW-Adressen der Produktanbieter auf, in denen weitere aktuelle Informationen zu einem vorgestellten Produkt enthalten sein sollen, doch auch die Medienanstalten, öffentlich-rechtliche wie private, politische Parteien und Vereine präsentieren sich über dieses neue Medium. Privatnutzer können in Internetbörsen Bewerbungen einreichen, eine elektronische Visitenkarte in Form einer Homepage bei einem Internetdienstanbieter (Provider) ablegen oder an Auktionen und "Online-Shopping" teilnehmen. Auch öffentliche Einrichtungen wie das Arbeitsamt nutzen das Internet zum Datenaustausch.


1.2. Neue Tendenzen bei der Internetnutzung

Der Personal Computer (PC) hat mittlerweile in breiten Schichten der Bevölkerung Akzeptanz gefunden. Die Computeranwendung beschränkt sich nicht mehr auf den Arbeitsplatz. Zunehmend füllt die Beschäftigung mit dem Computer auch den Freizeitbereich. Das Leistungsvermögen dieser Rechner und ihrer Hardwareperipherie steigert sich rasant, und die Anwendungsmöglichkeiten von Programmen wachsen mit dieser Entwicklung mit. Die Nutzungsmöglichkeit von Netzwerkdiensten wird zunehmend zur Grundanforderung an den PC. Bei vielen Rechnern gehört ein Modem schon zur Standardausstattung, ISDN-Karten oder externe Anschlüsse sind nachrüstbar, und die über herkömmliche Telefonleitungen erfolgende Anbindung an Online-Dienste ist wegen des auf diesem Sektor einsetzenden Wettbewerbs der Anbieter allmählich auch für private Nutzer erschwinglich, selbst wenn eine solche Entwicklung nicht von Dauer sein kann[1]. Unter diesen Voraussetzungen steht der Zugang zum Internet/WWW breiten Schichten offen. Die dort vorhandenen Daten sind für jeden Computernutzer mit Internetanschluß zugänglich.

Doch auch für diejenigen, die (noch) keinen Computer besitzen, soll das Internet erschlossen werden. Verschiedene Lösungen für herkömmliche Fernsehgeräte sind in der Planung. Die Firma Navio Communications, eine Tochterfirma der Firma Netscape, entwickelt den WWW-Browser "Navigator" für Fernsehgeräte und später für Unterhaltungselektronikgeräte. Auch auf der Geräteseite wird nach neuen Konzepten gesucht. Hitachi, ein großer japanischer Elektronikspielzeughersteller arbeitet bereits an der Herstellung einer erschwinglichen Internetkonsole[2], die an Fernsehgeräten betrieben werden kann.


1.3. Strukturprobleme des Internet

Wer den Anschluß ans Internet vorgenommen hat, stellt bald fest, daß der Zugang zu Daten auf diesem Netz zwar leicht ist, eine Auswertung solcher Daten sich aber bisweilen sehr aufwendig gestaltet. Eine Recherche zu einem Thema beginnt mit einer Suche nach Adressen von Datenanbietern. Hierzu stehen Internet-Suchdienste zur Verfügung. Sie ermöglichen eine mehr oder weniger komfortable Suche auf dem aktuellen Bestand des Internet bzw. des WWW, indem Suchbegriffe und, je nach verwendetem Dienst, weitere Begriffe aus dem Kontext des gesuchten Begriffs eingegeben werden. Eine Eingrenzung der Daten, die auf eine Suchabfrage hin geliefert werden und nun durchsucht werden sollen, ist nur eingeschränkt möglich. Daher führt eine solche Stichwortsuche nicht gleich zu einem Erfolg. Die große Menge der gefundenen Datenadressen enthält häufig redundante Informationen durch Doppeleinträge. Dies sind auf unterschiedlichen WWW-Seiten gefundene Verweise, welche auf jeweils dieselbe Datenquelle verweisen. Ärgerlicher sind gefundene Adressen, die inzwischen im Zuge einer Aktualisierung der entsprechenden WWW-Seiten durch deren Anbieter einen anderen Namen erhalten haben oder gar nicht mehr existieren. Eine Suche im Bereich von Spezialgebieten endet oft ohne Ergebnis, weil noch kein aktuelles, elektronisch aufbereitetes Material vorliegt bzw. vorhandene Bibliothekskataloge erst nach und nach über Datenbanken zugänglich gemacht werden. So gestaltet sich eine Recherche über das Internet momentan noch nicht einfacher oder erfolgreicher als eine bisherige konventionelle Recherche und kann diese bestenfalls ergänzen.

Ursache für den beschriebenen "Organisationsnotstand" im Internet ist die Entwicklung dieses Netzes aus der Struktur des ARPA-Netzwerks. Dieses Netz war, wie bereits erwähnt, als dezentrale Anlage organisiert worden, und das sowohl im Bereich der Hardware wie auch in der Datenhaltung, weil militärische Angreifer im Netzwerk selbst wie auch bei den Daten keine Möglichkeit bekommen sollten, durch Störung einer Zentralstelle das gesamte Netz auszuschalten. Auch später schien eine Sammlung von Daten in Zentralarchiven nicht nötig, da die Rechner, die entsprechende Daten beinhalteten, über das Netz direkt verfügbar waren. Heute ist der Datenbestand so riesig, daß eine zentrale Datenhaltung für das Internet oder für Teilbereiche daraus einen ungeheuren technischen und materiellen Aufwand erfordern würde. Ohne eine Strukturierung dieser Datenmassen und ohne Navigationshilfen aber wird das Auffinden von Informationen allein schon durch die Menge der zu durchsuchenden Daten zunehmend schwieriger.

Das Zeitgeistphänomen des "Surfens" im Internet, des Reitens auf einer Datenwelle dieses "Informationsozeans" und das schnelle Wechseln auf eine andere, ist also nur zum Teil bewußtes freies Bewegen auf dem Gesamtdatenbestand des Netzwerks. Es zeigt gleichzeitig die Achillesferse dieses Systems auf, nämlich die fehlenden Instrumente zur Strukturierung und Katalogisierung dieses riesigen, sich ständig ändernden und erweiternden Datenmolochs. Zu schnell verliert der "Surfer" die Blickverbindung zum rettenden Ufer und wird Opfer des "Lost-in-Cyberspace"-Syndroms.


1.4. Leitungsprobleme

Das größte Hindernis für ein funktionierendes Recherchieren im Internet/WWW ist die beschränkte Kapazität der zur Verfügung stehenden Übertragungsleitungen. Ein noch so dichtes Netz an Einwählpunkten und größte Bemühungen in der Hardware- und Softwareoptimierung auf der Rechnerseite können nicht verhindern, daß die Kabel der Telefongesellschaften und die Kapazität von Satelliten durch die zunehmende Nutzung dieses Mediums zu Stoßzeiten den Anforderungen nicht mehr gewachsen sind. Unter den Ruf nach dem Internet als einem schnellen weltweiten Informationsmedium mischt sich mittlerweile das Murren über den permanenten Stau auf dieser "Datenautobahn". Da die Zahl der angemeldeten Internetanschlüsse immer noch schneller wächst als der Ausbau der Verbindungen, ist für die nächsten Jahre in dieser Hinsicht keine Besserung zu erwarten. Die Verlagerung eines Teils der Internetanschlüsse auf das Fernsehen bringt zwar möglicherweise auch eine Verlagerung eines Teils der Leitungslast auf das Kabelfernsehnetz bzw. auf Fernsehsatelliten mit sich. Doch erst eine Versorgung mit den erheblich leistungsfähigeren Glasfaserkabeln als Übertragungsleitungen - anstelle der momentan genutzten Kupferkabel - wird hier eine deutliche Entlastung dieses Problems erzielen und Projekte wie Online-Nachrichten[3], Video-Conferencing mit Bild- und Tonübertragung in Echtzeit und weitere bereits geplante datenintensive Internetanwendungen ermöglichen, die derzeit nur mit Hilfe von Standleitungen zufriedenstellend funktionieren.


2. PRISMA - Ein Bildrecherche- und Informationssystem für Moderne Kunst - Beschreibung des Projekts

Der Anschluß von einzelnen Datenbanken an das WWW ist zum Teil nur unter enormem Aufwand möglich und Datenbankbetreiber müssen entscheiden, ob sich dieser Schritt tatsächlich lohnt. Bleibt man anschließend bei der herkömmlichen Nutzung einer Datenbank, gewinnt man durch den WWW-Zugang weder eine Steigerung in der Verarbeitungsgeschwindigkeit, noch wird das bisher genutzte Leistungsspektrum der Datenbank wesentlich erweitert. Im Gegenteil, durch die Abbildung von Datenbankinhalten über die grafische Oberfläche eines WWW-Browsers dürfte sich die Kommunikation mit einer Datenbank in den meisten Fällen verlangsamen, und die Anforderungen an den benutzten Rechner können steigen. Außerdem lassen sich nicht alle Datenbankformate in die für das WWW erforderlichen Standarddatenformate umwandeln oder sind nach einer Umwandlung umständlicher zu bearbeiten. Auch die geschützte Übertragung von Daten stellt im Internet ein Problem dar, da solche Daten bisher nicht verschlüsselt werden. Die Vorteile einer Internetanbindung, wie die Plattformunabhängigkeit, weitgehende Softwareunabhängigkeit und die Möglichkeit des weltweiten Zugriffs, sind gegen die genannten Nachteile abzuwägen.

Augenblicklich wachsen weltweit die Bestrebungen, Datenbanken an das WWW anzubinden [2] und reine Informationsseiten zu interaktiven Seiten weiterzuentwickeln, um sie als Schnittstelle für Anwendungen zu nutzen[4]. Über die von WWW-Servern interpretierbaren Common Gateway Interface- (CGI-) Skripte hinaus erweitern Programme in der plattformunabhängigen Programmiersprache JAVA bzw. Erweiterungen für WWW-Browser, sogenannte Plug-Ins[5], das Spektrum für multimediale Darstellungen.

Vor diesem Hintergrund eines expandierenden Internets mit einer ständig wachsenden Zahl von angeschlossenen Datenbanken und Informationssystemen stellt sich die Frage nach Sinn und Bedeutung der Entwicklung weiterer Konzepte für WWW-Informationssysteme.


2.1. Allgemeine Beschreibung des PRISMA-Projekts

Das Projekt PRISMA (Picture Retrieval and Information System for Modern Arts) entwickelt ein Konzept für ein System zur einheitlichen Verwaltung von verteilten objektorientierten Datenbanken (OODB) unter Nutzung des Internetdienstes WWW.

Bei Einhaltung der WWW-Standards im Betrieb eines solchen Informationssystems ist eine plattformunabhängige Anbindung verschiedener Benutzer möglich. Für die von einer Datenbank zu leistenden Aufgaben, wie den Transport von Daten oder den Zugriff auf die Daten zur Änderung, Erweiterung oder Recherche können verschiedene Dienste des Internet benutzt werden. Wenn die Benutzeroberflächen der zu entwickelnden Softwarewerkzeuge ebenfalls mittels Standardformaten dargestellt werden können, ist eine weitgehende Softwareunabhängigkeit der Anwendung ebenfalls gewährleistet. Diese Überlegungen führten zu der Entscheidung, das Internet als Kommunikationsmedium für dieses System zu wählen.

Eine Erweiterbarkeit des Systems in Hinblick auf die mögliche Anbindung relationaler Datenbanken und auf die Verwaltung von WWW-Daten sowie in Hinblick auf weitgehend freie Nutzungsmöglichkeiten des Systems für unterschiedliche Anwendungen waren von Beginn an mitentscheidend für die Projektgestaltung.


2.2. Präzisierung der Projektziele

2.2.1. Strukturierung von Daten bei dezentraler Datenhaltung

Mit Hilfe von OODB sollen auf Rechnern unterschiedlicher Hardwareausführung und unterschiedlicher Konfiguration verteilte und von ihrem Aufbau her heterogene Informationen umstrukturiert und unter einer einheitlichen Benutzeroberfläche verwaltet werden. Eine Hauptaufgabe hierbei ist es, Strukturierungskonzepte zur bestmöglichen Verteilung von Daten nach inhaltlichen und datenbankspezifischen Gesichtspunkten, zur effizienten Suche im Gesamtdatenbestand und zur graphischen Formulierung von Anfragen auf verteilten Datenbeständen zu entwickeln, und das unter Verwendung herkömmlicher Standards.

Zur Evaluierung dieses Konzepts wurde zum Ziel gesetzt, ein Informationssystem zur Kunstrichtung des Kubismus zu implementieren, da hier vorhandenes Datenmaterial des Vorgängerprojekts PARES (Picture Administration and Retrieval System[6]) verwendet und ausgebaut werden konnte [6]. Außerdem ist die Archivierung und Verwaltung multimedialer Daten (Bilder, Tondokumente, Animationen) in einer solchen Anwendung möglich und sinnvoll. Der vorhandene Datenbestand aus dem PARES-Projekt soll durch eigene zusätzliche Daten zu diesem Anwendungsgebiet, aus externen Datenbanken und aus WWW-Daten erweitert werden.


2.2.2. Verwaltung flüchtiger" Daten

Die fehlende Struktur im Datenbestand des Internet wurde bereits als eines der Hauptprobleme für einen Informationssuchenden beschrieben. Die im "Datenozean" des WWW auffindbaren Daten lassen sich grundsätzlich in zwei Kategorien unterteilen. Zum einen findet man dort "flüchtige" Daten, die sich als ein Gebilde aus HTML-Dokumenten präsentieren und über einen WWW-Server aus einem Verzeichnis aufgerufen werden. Hierzu zählen z.B. Homepages und kleinere Informationsseiten sowie FTP-(file transfer protocol-)Dateien, die nach einer Aktualisierung oder durch einen Namenswechsel der Datei nicht mehr auf dieselbe Weise wie vorher aufzufinden sind bzw. ganz verschwinden. Zum anderen lassen sich "beständige" Daten finden, die von einer Datenbank verwaltet werden.

Bei dem Versuch, auch nur einen Teil der verfügbaren WWW-Daten zu strukturieren, stellt das Auffinden und Aktualisieren der "flüchtigen" Daten den größeren Aufwand für die Administratoren des Informationssystems dar. Als Werkzeug zur Unterstützung bei dieser Aufgabe wird ein WWW-Parser [7] entwickelt, der das Auffinden und Analysieren von themenspezifischen HTML-Konstrukten durch deren Strukturierung vereinfachen soll[7]. Trotzdem bedarf es einigen Aufwandes seitens des Datenbankadministrators, den Inhalt dieser HTML-Konstrukte auszuwerten und mit dem Gesamtdatenbestand abzugleichen. Eine Verwertung dieser Daten ist auf verschiedene Weise durchführbar. Sind in HTML-Seiten neue Daten enthalten, werden sie entweder in eine lokale Datenbank des Informationssystems aufgenommen und so zusammen mit dem Bestand an "festen" Daten verfügbar gemacht oder ihre Adresse, der Uniform Resource Locator (URL), wird als Adresse im Informationssystem aufgenommen. Letzteres ist nur bei solchen HTML-Seiten sinnvoll, die permanent denselben Inhalt und denselben URL behalten. Eine so aufwendige Auswertung läßt sich nur sehr eingeschränkt automatisieren, verhindert aber die Speicherung redundanter Daten innerhalb des Systems.


2.2.3. Verwaltung "beständiger" Daten

Auf dem Internet/WWW verfügbare Datenbanken lassen einen Überblick auf die in ihnen enthaltenen Daten nicht zu. Trifft ein Suchender auf eine Datenbank, muß er deren WWW-Schnittstelle benutzen und kann dann innerhalb dieser Datenbank recherchieren. Je nach Typ und Implementation fallen solche Schnittstellen unterschiedlich aus. Einige neuere Datenbanken verfügen über eine eigene WWW-Schnittstelle, andere werden über angefügte CGI-Schnittstellen für den WWW-Zugriff verfügbar gemacht. Das verlangt einem Suchenden jeweils die Mühe der Einarbeitung in die entsprechende Benutzeroberfläche ab.

Das angestrebte Informationssystem soll hier Abhilfe schaffen, indem verschiedenen Datenbanken mit WWW-Schnittstelle ein System verteilt arbeitender objektorientierter Datenbanken als Verwaltungsdatenbank übergeordnet wird. In einem solchen System werden typgleiche Daten aus verschiedenen Datenbanken in Form von Adressen zu den Originaldatensätzen transparent verwaltet. Der Benutzer erhält so einen Überblick über den Gesamtdatenbestand des Informationssystems, ohne die angeschlossenen Datenbanken separat durchsuchen zu müssen. Neben den Datensätzen der projekteigenen Datenbanken[8] sollen auch Datensätze externer wissenschaftlicher Datenbanken für Abfragen verfügbar gemacht werden. Datenadressen aus deren Datenbeständen können über die Benutzeroberfläche des Informationssystems zur Verfügung gestellt werden, wenn ihre Datenstruktur auf das PRISMA-Informationssystem adaptiert wurde. Eine solche Verwaltung von Adreßdaten ermöglicht ein plattformunabhängiges, freies oder geleitetes Recherchieren innerhalb des Informationssystems, selbst dann, wenn nicht alle der angeschlossenen Datenbanken objektorientierte Datenbanken sind[9]. Figur 1 zeigt die Funktionsweise des PRISMA- Systems.

Bild

Figur 1: PRISMA dient als komfortable Verbindung zwischen Datensuchenden und verschiedenen Datenquellen.


2.2.4. Verteilte Verwaltung des Informationssystems

Das Vorhaben, zu einem Zeitpunkt eines stark expandierenden Internets eine Strukturierung seines Datenbestands durchzuführen, ist technisch nur schwer und unter enormem Einsatz von Mitteln zu leisten. Eine Zentralisierung von Daten an einer Informationsstelle würde deren Kapazitäten bald überfordern und den Zugriff auf Daten im Vergleich zu den bestehenden Verhältnissen vielleicht noch verlangsamen. Die dezentrale Datenhaltung auf dem Internet kann durch einen zenralen Index nicht sinnvoll erweitert werden. Eine Strukturierung von Daten muß also auf niederer Ebene einsetzen, etwa im Sinne themenbezogener Informationssysteme, die allmählich erweitert werden. Die hieraus entstehende Struktur kann dann über mehrere verteilt arbeitende OODB, die sich gegenseitig aktualisieren, quasi dezentral zur Verfügung gestellt werden. Ein solches System wäre bei Bedarf erweiterbar, denn bei einer Auslastung dieser Anlage können beliebig viele weitere Verwaltungsdatenbanken in die Anlage eingebunden werden. Ein solches System betreibt eine gewisse Zentralisierung von Daten, indem innerhalb des Informationssystems die Adreßdaten zentral verwaltet werden, dafür ist die Anzahl solcher Zentralstellen offen.


2.2.5. Verwendung von WWW-Standards


2.3. Der Aufbau des Informationssystems

2.3.1. Die Benutzerseite des Informationssystems

Grundsätzlich läuft der Datentransport zwischen einem Datensuchenden und dem konzipierten Informationssystem über dieselbe Infrastruktur und dieselben Transportmechanismen wie eine Anfrage im Internet. Grob lassen sich zwei Bereiche voneinander unterscheiden. Zum einen der Benutzer mit seinem Endgerät, einem nicht näher bestimmten Computer, und einem Internet/WWW-Zugang, zum anderen die Datenbankseite, die ihre Funktionen und Daten für einen solchen Benutzer bereithält und über einen WWW-Server erreichbar ist. Beide Bereiche sind durch ein Übertragungsnetz miteinander verbunden und kommunizieren über Standardprotokolle.

Im ersten Bereich, in der Benutzerebene, werden die Zugriffsmöglichkeiten von Benutzern auf die Daten des Informationssystems geregelt. Grundsätzlich soll ein plattformunabhängiger Zugriff auf das System über einen herkömmlichen WWW-Zugang ermöglicht werden. Für das Informationssystem gibt es aber unterschiedliche Nutzungsweisen, abhängig davon, für welche Art des Zugriffs ein Benutzer autorisiert ist. Hier gibt es Interessenten, die das Informationssystem benutzen, um sich zunächst einen allgemeinen Eindruck zu verschaffen oder eine gezielte themenbezogene Recherche durchzuführen. Dann gibt es die eingetragenen Benutzer der angeschlossenen Datenbanken, die Administratoren, die zu den allgemeinen Funktionen eine Option zur Datenmanipulation in ihrem Zuständigkeitsbereich benötigen, und schließlich Kunden, die sich Teile des Datenbestandes zu eigenen thematischen Führungen zusammenstellen wollen. Das Informationssystem soll also als komfortabler "multimedialer Karteikasten" für eine allgemeine Recherche dienen, als Werkzeug zur Archivierung sowie für Forschung und Lehre fungieren und als Autorensystem für Multimediaanwendungen nutzbar sein.

Bild

Figur 2: Der Aufbau des Gesamtsystems

2.3.2. Die Versant-Verwaltungsebene


3. Softwarekomponenten und Techniken

3.1. WWW als Frontend zu objektorientierten Datenbanken

Im Zuge einer Weiterentwicklung von Internet-Applikationen über das einfache Abrufen von Dokumenten hinaus ist es notwendig, persistente Informationen effizient zu speichern und zur weiteren Verwendung über das WWW zur Verfügung zu stellen.

Wegen der Popularität, der universellen Verfügbarkeit (Plattformunabhängigkeit) und der einfachen Bedienung von WWW-Browsern liegt der Gedanke nahe, Datenbankinformationen auch über WWW anzubieten - Der WWW-Browser wird zum Datenbankfrontend. Die Anbindung von Datenbanken ans WWW kann dabei durchaus unterschiedlich motiviert sein:

Während die meisten Datenbanken, für die ein WWW-Frontend entwickelt wurde, zum Typ der relationalen Datenbanken gehören, beschäftigen wir uns im folgenden mit der Verbindung von objektorientierten Datenbanken und WWW-Technologie.

3.2. Objektorientierte Datenbanken

Objektorientierte Datenbanken (OODBen) haben ihre Wurzeln in den objektorientierten Programmiersprachen. Motiviert wurde ihre Entwicklung in erster Linie durch sogenannte Non-Standard-Anwendungen (CAD, CASE usw.), wo es sich zeigte, daß die Möglichkeiten traditioneller, relationaler Systeme nicht mehr ausreichen, um die komplexen Zusammenhänge hochstrukturierter Informationen modellieren bzw. effizient Verwalten zu können. Objektorientierte Modelle sollen hier Abhilfe schaffen. Als wesentliche Entwicklungsziele lassen sich nennen:

Was hat man sich nun unter einem sogenannten Objektmodell vorzustellen? In Abgrenzung zu den imperativen Programmiersprachen (PASCAL, C usw.), wo aktive Funktionen auf passiven Daten operieren, gibt es beim Objektmodell nur aktive Objekte, die auf Nachrichten anderer Objekte reagieren. Damit sind bereits zwei wichtige Begriffe bezüglich Objektmodell genannt. Weitere Begriffe, die in jeder Charakterisierung des Objektmodells verwendet werden, sind: Operation (Methode), Klasse, Vererbung, dynamisches Binden und Polymorphismus (Überschreiben von Methoden). Obwohl es keine einheitliche Definition des Begriffs "objektorientiert" gibt, ist man sich doch über die wesentlichen Prinzipien einig. Unter Verwendung und Erläuterung oben genannter Begriffe sind die Prinzipien in etwa die folgenden:

Im folgenden wollen wir den Object Database Standard, das Objektmodell der OMG[16] betrachten, das auch Grundlage für die weiteren Betrachtungen sein soll.


3.2.1. Der Object Database Standard

Im Gegensatz zur Entwicklung von relationalen Datenbanken (insbesondere SQL), hat man sich bei objektorientierten Datenbanken schon frühzeitig um eine Standardisierung bemüht. Auf diesem Gebiet hat die OMG bzw. die ODMG (Objekt Database Management Group) mit der Veröffentlichung von ODMG-93 [3], einem Dokument, in dem neben dem Objektmodell (Object Database Standard) auch die Datendefinitions- und Datenmanipulationssprache festgelegt sind, wesentliches geleistet. Aspekte des OMG-Objektmodells sind hier beschrieben:

In diesen Ausführungen erkennt man bereits wesentliche Teile des objektorientierten Paradigmas. Das ODMG-Objektmodell unterscheidet zwischen Typ und Klasse, wobei eine Klasse durch eine Schnittstellendefinition und eine bestimmte Implementierung festgelegt ist. Wir wollen hier Typ und Klasse nicht unterscheiden und den Begriff Klasse synonym für einen ODMG-Typ benutzen. Klassen sind im ODMG-Modell ebenfalls Objekte und haben sogenannte Klasseneigenschaften, insbesondere:

Neben den Klasseneigenschaften gehören zu einer Schnittstellendefinition noch:

In ODMG-93 sind vordefinierte Klassen beschrieben, die bereits eine Vererbungshierarchie bilden. Wurzel ist die Klasse Denotable_Object. Es wird dann zwischen veränderbaren (mutable) und unveränderbaren (immutable) Klassen unterschieden: Object und Literal (ver- bzw. unveränderbar bezieht sich dabei auf die Klasseninstanzen). Beide Klassen werden wiederum in atomare und strukturierte unterteilt. Hier ein Auszug aus einer Klassenhierarchie:

Denotable_Object
Object
Atomic_Object
. . .

Structured_Object
Collection
Set <T>
. . .

Structure <e1: T1, ... en: Tn>

Literal
Atomic_Literal
Integer
Float
. . .

Structured_Literal
. . .

Zu den Literalen zählen u.a. die üblichen Basistypen, wie z.B. Integer, Float, Character und Boolean. Sie gehören zu den atomaren Literalen. Strukturierte Objekte werden mit Hilfe von sogenannten Konstruktoren gebildet. So wird z.B. durch Set<Integer> eine Menge, bestehend aus Integerwerten, geschaffen.

Objekte der Klasse Structure können beliebig zusammengesetzt sein. Auch im ODMG-Objektmodell besitzt jedes Objekt eine eindeutige, unveränderbare Identität. Daneben kann ein Objekt aber auch noch einen oder mehrere Namen besitzen. Im Hinblick auf die Eigenschaften einer Datenbank ist die Kollektion (Collection) von zentraler Bedeutung. Eine Kollektion ist eine Container-Klasse, die Objekte, also Instanzen einer bestimmten Klasse, enthält. Bei Suchanfragen etwa wird im allgemeinen über alle Objekte einer bestimmten Kollektion iteriert. Zur Beschreibung der Schnittstellen hat die ODMG eine spezielle Schnittstellenbeschreibungssprache (ODL, Object Definition Language) definiert. ODL ist eine rein deklarative Sprache und soll die Portabilität von Datenbankschemata unterstützen.


3.2.2. Objektorientierte Datenbanksprachen

Für Anfragesprachen an OODBen werden wenigstens die gleichen Eigenschaften erwartet, wie für Datenbanksprachen, die auf anderen Modellen basieren:

Bei OODBen kann aufgrund des Datenmodells zwischen mengenorientiertem und navigierendem Zugriff unterschieden werden. Unter mengenorientiertem Zugriff sollen Iterationen über Kollektionen verstanden werden. Der navigierende Zugriff erlaubt das Auslesen von Attributwerten, das Verfolgen von Objektbeziehungen (Zugriff auf ein referenziertes Objekt) und das Ausführen von Methoden. Navigierender Zugriff wird über sogenannte Pfad-Ausdrücke realisiert (z.B. Person.Adresse.Straße).

Datenbanksprachen müssen Datenbankmanipulation erlauben. Diese Manipulationen kann man unter dem Begriff Update-Operationen zusammenfassen. Dazu gehören:


3.3. Ad-hoc-Abbildung von OODB-Objekten in HTML-Dokumente

Im folgenden wird die Entwicklung eines "auf die Schnelle" (ad hoc) implementierten Prototypen zur Anbindung einer OODB an das WWW dargestellt. Die bei dieser Implementierung gewonnenen Erfahrungen haben die Entwicklung von PRISMA entscheidend beeinflußt, indem u.a. dort erkannte Mängel vermieden werden bzw. Anforderungen schon in der Designphase von PRISMA einfließen konnten.


3.3.1. Probleme großer WWW-Server

Informationen, die über WWW verfügbar sind, liegen zur Zeit noch meist als HTML-Seiten in Form einzelner Dateien auf einem (WWW-) Serverrechner vor. Die Seiten sind untereinander durch Hyperlinks verbunden. Diese Art der Datenhaltung und -verwaltung kommt schnell an ihre Grenzen, wenn die Zahl der HTML-Seiten groß wird. Die Pflege vieler einzelner Seiten (also Dateien), insbesondere die Erhaltung ihrer Konsistenz, erfordert einen enormen Aufwand. Die Änderung des Inhalts einer Seite kann leicht ungeahnte Auswirkungen auf die mit ihr "verlinkten" Seiten haben. Auf diese Weise kommt es leicht zu den sogenannten "hängenden Verweisen" (dangling links), d.h. ein Hyperlink verweist auf nicht mehr vorhandene Zielanker. Die Folge ist eine Fehlermeldung des WWW-Servers: (-ERROR- (404): No such file or directory).

Dieses Problem wurde schon bald erkannt, und es wurde nach entsprechenden Lösungen gesucht. Inzwischen steht z.B. mit HyperG [4] ein System zur Verwaltung großer WWW-Server zur Verfügung. Ein wesentliches Designkriterium bei HyperG war die Verwendung von bidirektionalen Links, wodurch die Aktualisierung des gesamten Informationsbestandes bei Änderung einzelner Seiten weitgehend automatisiert werden kann. Hängende Verweise werden automatisch eliminiert.

Will man große Datenmengen über WWW zugänglich machen, wird die Verwendung einer Datenbank unumgänglich, insbesondere dann, wenn sich die darzustellenden Daten häufig ändern oder Benutzer selbst die Möglichkeit zur Dateneingabe erhalten.

In vielen Fällen ist bereits ein Datenbestand in einer Datenbank vorhanden, den man komplett oder nur in Teilen über WWW zugänglich machen will. Gleichzeitig möchte man evtl. Daten (z.B. Bestellungen), von Benutzern aufnehmen, die über einen WWW-Browser eingeben werden. Will man also mehr als nur wenige statische Seiten im WWW präsentieren, ist es sinnvoll, WWW- mit Datenbanktechnologie zu verknüpfen.


3.3.2. WWW-Frontend für eine objektorientierte Datenbank

Im Forschungsprojekt PARES wurde das Konzept einer Datenbank zum künstlerischen Werk Pablo Picassos unter Verwendung der OODB GemStone erstellt. Zur Darstellung des vorhandenen Datenbestandes wird ein WWW-Frontend entwickelt werden, um die Datenbankausgabe einer OODB mit den Darstellungsmitteln des WWW zu kombinieren und zu evaluieren.

Als ein System, das aus Objekten besteht, läßt sich eine OODB als Graph modellieren. Jedes Datenbankobjekt betrachten wir als einen Knoten, die Objektbeziehungen als die Kanten des Graphen. Auch HTML-Dokumente, die untereinander durch Hyperlinks verknüpft sind, lassen sich als Graph ansehen. Hier stellt jedes Dokument einen Knoten dar, die Hyperlinks die Kanten. Die Betrachtung von OODBen und HTML-Dokumenten als Graphen ist die grundlegende Idee für eine ad-hoc-Abbildung von Datenbankobjekten in HTML-Seiten und läßt sich durch die folgende Vorschrift beschreiben:

  1. Lies die Attribute eines Datenbankobjekts aus und stelle die Werte als ein HTML-Dokument dar.
  2. Erzeuge für jede Objektbeziehung einen HTML-Hyperlink in diesem Dokument.
  3. Stelle eine Kollektion von Objekten als Liste von Hyperlinks dar.

Auf diese Weise kann ein navigierender Zugriff auf eine OODB implementiert werden ("Surfen" in der Datenbank statt im Internet). Dazu wird für jedes darzustellende Datenbankobjekt ein korrespondierendes HTML-Dokument dynamisch erzeugt (die Informationen, die das Objekt trägt, werden in HTML "verpackt"). Der Ablauf einer Datenbankanfrage, das Erzeugen des entsprechenden Dokuments sowie seine Darstellung in einem WWW-Browser kann wie folgt skizziert werden:

Gegeben sei die folgende Konfiguration: Auf einem Rechner (im Internet) befinde sich die OODB (Datenbankserver) und ein WWW-Server. Auf dem gleichen Rechner oder auf einem beliebigen anderen Rechner mit Internetanschluß laufe ein WWW-Client (WWW-Browser), der bereits eine HTML-Seite mit einem Hyperlink auf ein oder mehrere Datenbankobjekt(e) anzeigt. Durch Anklicken des Links wird das referenzierte Objekt zur Darstellung in einem Browser aus der Datenbank angefordert. Dabei werden folgende Schritte ausgeführt:

  1. Der WWW-Browser sendet eine Anfrage. Diese besteht im wesentlichen aus einem URL, in dem die Adresse des Zielrechners bzw. WWW-Servers und die "Adresse" des gewünschten Objekts kodiert ist.
  2. Der WWW-Server empfängt die Anfrage und muß daraus die "Adresse" des Zielobjekts extrahieren. Mit dieser "Objekt-Adresse" wird eine Anfrage an die Datenbank abgesetzt.
  3. Die Datenbankanwendung (Datenbankserver) sucht mit Hilfe der übergebenen Objekt-Adresse das Objekt in der Datenbank und liest die Attributwerte aus. Diese werden dann in HTML kodiert, d.h. es wird ein HTML-Dokument erzeugt, das die Attributwerte in einer bestimmten Form anzeigt.
  4. Die Datenbankanwendung gibt das erzeugte HTML-Dokument an den WWW-Server als Abfrageergebnis zurück.
  5. Der WWW-Server sendet das HTML-Dokument an den WWW-Browser.
  6. Der WWW-Browser bringt das angefragte Objekt als neue HTML-Seite zur Anzeige.

Um die Kommunikation mit anderen Programmen zu realisieren, braucht der WWW-Server eine Schnittstelle. Diese Schnittstelle ist das Common Gateway Interface (CGI). Da dieses Interface bei der Implementierung der ad-hoc-Anbindung eine wesentliche Rolle spielt, soll es im folgenden kurz vorgestellt werden [5].


3.3.3. Programmieren des Common Gateway Interface (CGI)

Das CGI ermöglichte es als erstes, dynamisch generierte Information auf Anfrage eines Benutzers über das WWW zu präsentieren. Die Programmiersprache JAVA, eine weitere Möglichkeit zum Erstellen von interaktiven WWW-Seiten, geht in ihrem Potential, aber auch in ihrer Komplexität weit über CGI hinaus. Anders als JAVA ist CGI keine Programmiersprache, sondern Teil des WWW-Servers, eine Schnittstelle, über die der WWW-Server andere Programme aufrufen und ihnen benutzerspezifische Daten übergeben kann. Das aufgerufene Programm bearbeitet die Daten und der Server leitet die Antwort des Programms an den WWW-Browser weiter.

Eine der bekanntesten Anwendungen für CGI sind Formulare (Forms). Formulare sind eine Untermenge von HTML und können in einfacher Weise verwendet werden, um von einem Benutzer Informationen entgegenzunehmen. Sie können auch in komplexerer Weise verwendet werden, um einen Dialog mit dem Benutzer zu führen. Der kann beispielsweise Kriterien für eine Suche nach bestimmten Informationen liefern, die auf dem Serverrechner dazu verwendet werden, entsprechende Dokumente zu suchen bzw. dynamisch zu erzeugen. Diese Dokumente könnten dann wiederum Formulare beinhalten, die es erlauben, den Dialog fortzusetzen. Eine Anfrage über CGI sieht im wesentlichen aus wie der Aufruf eines WWW-Dokuments. Ein Beispiel:

http://www.prisma.de/prisma/cgi-bin/kommentar.cgi

Der WWW-Server erkennt (am Extender ".cgi"), daß das angeforderte Dokument ein CGI-Programm ist und versucht, dieses Programm (im obigen Beispiel kommentar.cgi) auszuführen, anstatt die Datei verbatim an den Browser zurückzugeben, wie er es mit einem HTML-Dokument (z.B. kommentar.html) tun würde.

Die Übergabe von Informationen an ein CGI-Programm hängt vom jeweiligen Betriebssystem ab. Unter UNIX bekommen CGI-Programme ihre Eingabe über den Standard-Input Kanal (STDIN) oder über sogenannte Umgebungsvariablen. Als Ausgabe produzieren CGI-Programme entweder ein HTML-Dokument oder liefern einen URL zu einem bereits existierenden Dokument. Die Ausgabe wird unter UNIX als Datenstrom auf den Standard-Output Kanal (STDOUT) geschrieben. Sie besteht aus zwei Teilen: Der erste Teil ist ein Header, der das Format, den MIME-Type, der nachfolgenden Daten beschreibt (z.B. HTML, plain text, GIF usw.). Der zweite Teil besteht aus den Daten, aus denen sich das im Header beschriebene Dokument zusammensetzt.

Um CGI-Programme zu erstellen, muß man sich einer konkreten Programmiersprache bedienen. Obwohl es im Grunde gleichgültig ist, welche Sprache man wählt, sind einzelne Programmiersprachen mehr oder weniger geeignet. Folgende Aspekte sollten von der gewählten Sprache unterstützt werden:


3.3.4. Das Verarbeiten von Benutzereingaben unter Verwendung des CGI

Wie bereits erwähnt, sind Formulare eine Möglichkeit, Daten eines Benutzers entgegenzunehmen. Der Benutzer "füllt das Formular aus", indem er über Listen, Radio- oder Optionsknöpfe die gewünschten Informationen auswählt bzw. Daten in Textfelder einträgt. Ein Formular enthält im allgemeinen einen "Abschicken"-Knopf, durch dessen Betätigung der Benutzer den Browser veranlaßt, das Formular an den WWW-Server zu übertragen. Das Verarbeiten von Benutzereingaben mit Hilfe von CGI-Programmen soll hier anhand eines Beispiels gezeigt werden.

Figur 3: Ein einfaches Eingabeformular

Zum Übertragen von Informationen kann man unter CGI zwischen den zwei Methoden GET oder POST wählen. Während die GET-Methode nur für geringe Datenmengen geeignet ist, kann die POST-Methode auch für große Datenmengen verwendet werden.

Fig. 3 zeigt eine einfaches Formular zur Entgegennahme von Benutzereingaben und Fig. 4 den zugehörigen HTML-Quellcode:

Figur 4: HTML-Code, der ein Eingabeformular beschreibt.

Auf der Serverseite werden die Daten, also der Name des CGI-Programms und die Formulardaten, abhängig von der gewählten Übertragungsmethode (GET oder POST), entweder in der Umgebungsvariablen QUERY_STRING abgelegt oder können vom STDIN gelesen werden. Das CGI-Programm, das die Eingabe verarbeitet könnte wie in Fig. 5 aussehen:

Figur 5: Ein CGI-Programm in Python

Das CGI-Script aus Fig. 5 ist in Python programmiert. Die erste Zeile gibt den Pfad zum Python-Interpreter an. Mit dem Befehl import werden benötigte Python-Module importiert. In diesem Fall sind es die Module posix, in dem die benötigte Funktion zum Auslesen der Umgebungsvariable QUERY_STRING implementiert ist (posix. environ()), und das Modul string, das Funktionen zur Stringmanipulation, u.a. zum Splitten eines Strings in Tokens enthält. Hier wird die Funktion (string.splitfields()) dazu verwendet, einen aus der Umgebungsvariablen ausgelesenen String z.B. kommentar=gut in die Tokens kommentar und gut zu splitten. Diese werden in der darauffolgenden Zeile den Variablen name und wert zugewiesen. Damit ist der vom Benutzer im Formular eingetragene Wert aus dem sogenannten CGI-String extrahiert und kann in einem nun an den Server (bzw. Browser) zurückzugebenden HTML-Dokument verwendet werden.

Das CGI-Script schreibt dazu einfach HTML-Code mit dem print - Befehl auf den STDOUT. Als erstes muß der HTML-Header ausgegeben werden, der den MIME-Type des Dokuments bezeichnet (Content-type: text/html) und durch zwei Zeilenumbrüche (\n\n) vom HTML-Körper (Body) getrennt ist. Dieser wird ebenfalls mit print-Befehlen ausgegeben. Nach Ausgabe von Header und Body ist das CGI-Programm beendet. Jetzt werden die Daten, die auf die Standardausgabe geschrieben wurden, vom WWW-Server an den Browser gesendet.

Im diesem Beispiel wurde ein Formular verwendet, um die Ausführung eines CGI-Programms zu veranlassen. Dies kann aber auch durch einen einfachen Link geschehen, wenn dieser auf ein solches Programm verweist. Anders als bei Formularen, wo die Eingabeparameter für das Programm aus den Benutzereingaben bestehen, müssen hier evtl. Parameter im URL bzw. Im Hyperlink selbst kodiert sein. Um das gleiche CGI-Programm mit den gleichen Parametern wie in obigem Beispiel über einen Link aufzurufen, müßte der URL die folgende Gestalt besitzen:

http://<Adresse des WWW-Servers>/cgi-bin/kommentar.cgi?

kommentar=gut

Die Syntax ist einfach: Das CGI-Programm (kommentar.cgi) wird wie ein gewöhnliches Dokument angesprochen. Die Parameter, die man dem Programm übergeben will, werden durch "?" vom Programmnamen getrennt in Form von Name=Wert-Paaren angefügt. Soll mehr als ein Name-Wert-Paar übergeben werden, werden diese durch "&" getrennt:

http://<Adresse des WWW-Servers>/cgi-bin/kommentar.cgi?

kommentar=gut&vorschlag=weitermachen

Damit sind die wesentlichen Techniken der CGI-Programmierung vorgestellt und wir können zur Implementation der ad-hoc-Anbindung übergehen.


3.3.5. Durchführung

Das Zusammenspiel der einzelnen Techniken bei der Implementierung des WWW-Datenbankfrontends soll am Beispiel eines vereinfachten Datenbankschemas dargestellt werden. Wir betrachten die Klassen Kuenstler, Bild und Image. Kuenstler besitze die Attribute Name, Vorname, Geburtsdatum, Sterbedatum, Lebenslauf sowie die Objektbeziehungen Portrait und Werke. Bild habe die Attribute Name, Entstehungsdatum, Technik sowie die Objektbeziehung Scan. Image besitze als einziges Attribut Imagedaten. Fig. 6 zeigt eine graphische Darstellung der Klassen.

Bild

Figur 6: Graphische Darstellung der Klassen Kuenstler, Bild und Image

Zur Darstellung: Die Objektbeziehungen sind hier mit Pfeilen unterstrichen. Der Doppelpfeil stigt an, daß eine Kollektion referenziert wird. In der Graphdarstellung sind die Objektbeziehungen "außerhalb" der Klasse dargestellt und verweisen auf das Objekt, das referenziert wird. Fig. 7 zeigt den entsprechenden Datenbankgraphen. Root sei die Wurzel des Graphen, eine Collection, die Objekte der Klasse Kuenstler enthält.

Bild

Figur 7: Graph des Datenbankschemas

Für unsere Implementierung müssen bestimmte Voraussetzungen bezüglich des Datenbanksystems bzw. der Klassen und Objekte erfüllt sein:

Ein Start-CGI-Programm oder eine statische HTML-Seite stellt das Wurzel-Objekt der Datenbank dar. Im Falle des Beispiels ist das Root-Objekt eine Kollektion von Kuenstler-Objekten. In HTML verpackt stellt die sich als eine Liste von Hyperlinks dar, welche auf die einzelnen Objekte verweisen. Fig. 8 zeigt diese Startseite.

Bild

Figur 8: Die Startseite mit Verweisen auf zwei Kuenstler-Objekte

Der zu diesem HTML-Dokument gehörige Code lautet:

<HTML>
<HEAD><TITLE>Startseite</TITLE></HEAD>
<BODY>
<H1>Startseite</H1>
<HR>
Collection Kuenstler <BR>
<UL>
<LI><A HREF=/cgi-bin/getObject.cgi?objectId=1234>Kuenstler</A>
<LI><A HREF=/cgi-bin/getObject.cgi?objectId=7890>Kuenstler</A>
</UL>
</BODY>
</HTML>

Das Dokument zeigt für jedes Objekt seinen Klassennamen. Die Objekt-Id des zugehörigen Objekts ist unsichtbar im Hyperlink enthalten. An dieser Stelle müßte statt des Klassennamens ein Name oder ein Schlüssel des jeweiligen Objekts angezeigt werden, damit man die Objekte unterscheiden kann (vgl. dazu Fig. 8). Im allgemeinen Fall kann man aber nicht davon ausgehen, daß ein beliebiges Objekt einen aussagekräftigen Namen oder Schlüssel besitzt. In PRISMA werden daher Objekte so entworfen, daß sie in jedem Fall über einen Namen verfügen. Folgt man nun einem der angezeigten Links, startet der WWW-Server das angegebene CGI-Programm (getObject.cgi) mit dem entsprechenden Parameter (der Objekt-Id). Das CGI-Programm (bzw. weitere Programme, die das CGI-Programm benutzt) muß folgende Schritte ausführen:

  1. Anfrage an die Datenbank: Finde das Objekt mit der als Parameter übergebenen Objekt-Id.
  2. Stelle die Klasse des gefundenen Objekts fest.
  3. Wenn das Objekt keine Kollektion ist, dann:
  4. für alle Eigenschaften des Objekts:
  5. Stelle fest, ob ein einfaches Attribut oder eine Objektbeziehung vorliegt
  6. Wenn einfaches Attribut vorliegt:
  7. Lies den Attributwert aus und verpacke ihn in HTML-Code in der Form Attributname: Attributwert.
  8. Sonst:
  9. Es liegt also eine Objektbeziehung vor: Ermittle Objekt-Id und Klasse des referenzierten Objekts und verpacke diese Daten in HTML-Code in der Form:<A HREF=/cgi-bin/getObject.cgi? objectId= Objekt-Id > Klasse </A> (erzeuge Hyperlink )
  10. Sonst:
  11. Das Objekt ist also eine Kollektion: Erzeuge eine HTML-Liste wie folgt: Für alle Objekte der Kollektion:
  12. Ermittle Objekt-Id und erzeuge HTML-Listeneintrag der Form: <A HREF=/cgi-bin/getObject.cgi?objectId=Objekt-Id >Klassenname</A> (erzeuge ein Hyperlink als Listeneintrag)
  13. Gib das erzeugte HTML-Dokument an den Server zurück

Der WWW-Server übergibt die Ausgabe des CGI-Programms unbesehen an den WWW-Browser, welcher das dynamisch erzeugte Dokument, das ein Objekt darstellt, zur Anzeige bringt.

Enthält das Dokument keine Hyperlinks, so hat man ein Blatt im Datenbankgraphen erreicht. Enthält es aber Links, so verweisen diese auf vom aktuellen Objekt referenzierte Objekte. Durch Anklicken eines Links kann der Datenbankgraph weiter verfolgt, "im Datenbankgraph navigiert" werden.

Fig. 9 zeigt das HTML-Dokument, wie es entsprechend obiger Vorschrift aus einem Kuenstler-Objekt erzeugt wurde. Der HTML-Code dieser Seite hat folgende Gestalt:

<HTML>
<HEAD>
<TITLE>Objekt der Klasse Kuenstler</TITLE>
</HEAD>
<BODY>
<H2>Objekt der Klasse Kuenstler</H2>
<B>Name: </B>Gris
<BR>
<B>Vorname: </B>Juan
<BR>
<B>Geburtsdatum: </B>1887
<BR>
<B>Sterbedatum: </B>11.05.1927
<BR>
<B>Lebenslauf: </B>
Juan Gris wurde in Madrid im Jahre 1887 als Kind ...
<BR>
<B>Portrait: </B>
<A HREF="=/cgi-bin/getObject.cgi?objectId= 4567"> Image</A>
<BR>
<Werke: </B>
<A HREF="=/cgi-bin/getObject.cgi?objectId= 5678"> Bilder</A>
<BR>
<P>
<HR>
</BODY>
</HTML>
>


Bild

Figur 9: Ein Objekt der Klasse Kuenstler, wie es im Browser erscheint.

Die bis hierher vorgestellte ad-hoc-Abbildung eines objektorientierten Datenbankschemas in HTML kann nur eine erste Annäherung an ein WWW-Frontend für eine OODB sein. Eine Reihe von Mängeln ist offensichtlich:

4. Implementierung des PRISMA-Systems

4.1. Voraussetzungen/Motivation

Bisher sind wir von einem bereits bestehenden Datenbankschema ausgegangen. Datenbankobjekte können auf relativ einfache Weise in einem WWW-Browser sichtbar gemacht werden. Dabei zeigen sich aber auch eine Reihe von Unzulänglichkeiten, die zum Teil in der ad-hoc-Methode des Vorgehens begründet sind. Wie beschrieben erscheinen im Browser "rohe". Datenbankobjekte. Man müflte die Darstellung der Objekte beeinflussen können, d.h., die Objekte müflten nach Auslesen aus der Datenbank für die Darstellung im Browser den Angaben des Administrators oder Autors entsprechend formatiert werden.

Ein weiterer Punkt ist, dafl auf die Datenbank selbst kein Einfluß genommen werden kann. Änderung von Objektattributen oder Eintragen von neuen Objekten, typische Datenbankoperationen, sind bisher über den Browser nicht möglich. Das mufl nicht unbedingt ein Nachteil sein. Sicher soll einem "normalen" Benutzer nicht ein beliebiger Zugriff auf die Daten gestattet sein. Doch kann es sinnvoll sein, einem Datenbankadministrator über WWW-Browser auch einen manipulierenden Zugriff auf die Datenbank zu erlauben, sei es, um ihm eine einheitliche Benutzeroberfläche zu bieten, sei es, weil er auf diese Weise von einem beliebigen Client im Internet Datenbankoperationen ausführen kann.

Im PRISMA Projekt war ein erstes Ziel, eine Datenbankoberfläche für objektorientierte Datenbanken über WWW zur Verfügung zu stellen. Diese soll neben dem "Surfen" in der Datenbank einem Administrator manipulierende Operationen wie das Eintragen oder Löschen von Objekten oder das [florin]ndern von Attributwerten und Objektbeziehungen bestimmter Objekte erlauben.

Anders als bei der ad-hoc-Abbildung einer bereits existierenden Datenbank haben wir nun eine zunächst "leere" Datenbank. Das Datenbankschema und insbesondere die Klassen können daher den eigenen Vorstellungen entsprechend gestaltet werden. Die Anforderungen an die Datenbank bzw. an die WWW-Benutzeroberfläche seinen hier noch einmal zusammengefaßt.

Prototypisches Anwendungsgebiet des PRISMA-Systems ist ein Informationssystem zur Kunst des Kubismus. Es ist daher eine wesentliche Forderung, dafl die Verarbeitung von graphischen Daten und deren Verknüpfung mit textuellen Daten besonders gut unterstützt wird.

Die gerade beschriebenen Anforderungen sind die künstlerischen Datenbankanforderungen des KDBA. Er soll umfangreiche Manipulationsmöglichkeiten in bezug auf die Daten sowie in einem gewissen Rahmen Einflufl auf die Datenbankstruktur selbst erhalten.

PRISMA soll neben Objekten, die in der (den) prismaeigenen Datenbank(en) abgelegt sind, auch Dokumente des WWW mitverwalten können. Das bietet dem KDBA die Möglichkeit, auf Informationen im WWW zu verweisen, bzw. solche nahtlos in "PRISMA-Dokumente" zu integrieren. Eine redundante Datenhaltung kann so weitgehend vermieden werden.


4.2. Die PRISMA-Klassen

4.2.1. Die Basisklassen der PRISMA-Datenbank

Auf der Basis der Ergebnisse zur Vermeidung der Mängel der Ad-hoc-Anbindung einer OODB, und für die Realisierung der oben genannten Anforderungen wurden die Klassen für die PRISMA-Datenbank entworfen.

PRISMA-Dokumente bestehen, dem Anwendungsgebiet entsprechend, im wesentlichen aus Text und Graphik. Mit Blick auf den ständig wachsenden Leistungsumfang des WWW empfahl es sich, auch die Verwaltung von Audio-, Video- und 3D-Daten vorzusehen.

Eine grundlegende Aufgabe des PRISMA-Informationssystems ist es, dem KDBA zu erlauben, aus den in PRISMA-Datenbanken gespeicherten Daten, falls nötig unter Einbeziehung von Daten externer Datenquellen, neue Dokumente zu erstellen. In diesem Sinne kann PRISMA als Autorensystem betrachtet werden. Folglich werden in der Datenbank nicht hauptsächlich fertige Dokumente sondern vielmehr die dazu nötigen Informationsbausteine gespeichert werden müssen. Ein typisches WWW-Dokument, bestehend aus Text- und Graphikbausteinen, zerfällt unter PRISMA in die einzelnen Text- und Graphikobjekte, die auch allein darstellbar sind, bzw. Bestandteile vieler weiterer Dokumente sein können. In Anlehnung an das Modell des Aufbaus der Materie haben wird diese kleinsten, nicht mehr teilbaren Dateneinheiten Datenatome genannt.

Die momentane Implementierung beruht auf den folgenden Basis-Datenbankklassen:

Aus implementationstechnischen Gründen wurde eine spezielle PRISMA-Basisklasse entworfen, die Oberklasse aller PRISMA-Klassen ist. Diese "Wurzelklasse" heißt PrismaObject. Sie ist wie DatenAtom eine abstrakte Klasse und faflt Objekteigenschaften zusammen, die von jedem Objekt benötigt werden, um im PRISMA-System zu funktionieren. Hierzu gehört u.a. die manipulierbare Darstellung von PRISMA-Objekten im WWW-Browser, auf die im folgenden noch eingegangen wird.

Die PRISMA-Klassenhierarchie stellt sich also zunächst wie folgt dar:

PrismaObject
DatenAtom
GIFAtom
JPEGAtom
HTMLAtom
MIDIAtom


4.2.2. Zusammengesetzte Klassen in der PRISMA-Datenbank

Die Objekte der oben beschriebenen Basisklassen dienen als "Bausteine" für zusammengesetzte Informationseinheiten, z.B. eines WWW-Dokuments, das aus Text und Graphik besteht. Im Hinblick auf die kunstwissenschaftliche Anwendung kann ein solches "Dokument" beispielsweise ein Bild des Künstlers Juan Gris einschließlich seiner Beschreibung sein. Es setzt sich zusammen aus der Abbildung in GIF- oder JPEG-Format und beschreibenden Attributen wie der verwendeten Maltechnik, dem Entstehungsjahr und einem Verweis auf den Künstler und die Entstehungsgeschichte des Bildes. Ein solches Bild-Dokument könnte Teil einer umfassenderen Beschreibung des Werkes von Juan Gris oder einer "virtuellen Ausstellung" zum Thema "Kubismus" sein, durch die ein Benutzer mit Hilfe seines WWW-Browsers "surft". Unter objektorientierter Betrachtungsweise, ist Bild eine Klasse, und ein bestimmtes Bild des Künstlers Gris, wie oben beschrieben, ist ein Exemplar, ein Objekt dieser Klasse. Weitere Objekte können andere Bilder von Gris oder von anderen Künstlern darstellen. Bild ist eine zusammengesetzte Klasse, da sie neben Attributen auch Objekte der Basisklassen und andere zusammengesetzte Objekte, wie Kuenstler umfaßt.

Bild

Figur 10: Eine zusammengesetzte Klasse Bild

Die Basisklassen wie GIFAtom oder HTMLAtom sind im PRISMA-System vorgegeben. Wie aber gelangen zusammengesetzte Klassen in das System? In PRISMA kann der KDBA solche Klassen nach Bedarf erzeugen. Das ist sinnvoll, denn lediglich mit einer bestimmten, vorgegebenen Menge von Klassen arbeiten zu können, macht das System beschränkt und unflexibel. Der Weg, jede benötigte Klasse vom informatischen Datenbankadministrator (IDBA) erzeugen zu lassen, schränkt den KDBA in seiner Arbeit zwar ein, ist aber zum Schutz der Klassen, die nicht für die Präsentation gedacht sind (Systemklassen u.ä.), unbedingt erforderlich. Konkret bedeutet das, daß der KDBA nur bestimmte Klassen, nämlich Unterklassen der PRISMA-Klasse DatenMolekuel erzeugen kann. DatenMolekuel wurde in Anlehnung an das oben bereits erwähnte "Atommodell" benannt[17] (man sollte die Parallelität zu diesem Modell allerdings nicht überstrapazieren). Diese Klasse ist die Wurzel aller vom KDBA erzeugbaren Klassen. Die Hierarchie der zusammengesetzten Klassen:

PrismaObject
DatenMolekuel
Bild
Kuenstler


4.3. Der Aufbau des Systems

Die oben beschriebenen Klassen befinden sich in der PRISMA-OODB. Sie ist der zentrale Bestandteil des PRISMA-Systems. Weitere Teile sind ein WWW-Server, der die Kommunikation mit dem PRISMA-Benutzungswerkzeug, einem WWW-Browser, übernimmt sowie eine Reihe von CGI-Programmen, die die Verbindung zwischen der Datenbank und dem WWW-Server herstellen. Datenströme, die zwischen den einzelnen Teilen flieflen, müssen bestimmte Bedingungen erfüllen. So verwenden die einzelnen Softwaremodule zur Kommunikation ein bestimmtes Protokoll. Im Falle von WWW-Server und WWW-Browser ist es das standardisierte Hypertext Transfer Protocol (http), im Falle von CGI-Programmen und der PRISMA-Datenbank ist es ein proprietäres Protokoll. Die Verbindung zwischen WWW-Server und den CGI-Programmen läuft, wie schon bei der ad-hoc-Anbindung über CGI.

Bild

Figur 11: Aufbau von PRISMA


4.3.1. Die Datenbank

Die von PRISMA verwendete Datenbank ist die OODB Versant mit Smalltalk-Schnittstelle. Implementationssprache auf Datenbankseite ist also Smalltalk; insbesondere sind die PRISMA-Basisklassen und die vom KDBA erzeugten Klassen in Smalltalk implementiert. Der KDBA muß für die von ihm benötigten Klassen keinen Smalltalk-Code entwickeln, sondern kann Klassen im wesentlichen durch Angabe von Namen und Attributen beschreiben. PRISMA übersetzt die Beschreibung, erzeugt den entsprechenden Smalltalk-Code, führt ihn aus und erzeugt so die gewünschte Klasse. Auf die gleiche Weise ist die Datenmanipulation, also das Ändern von Attributen und Objektbeziehungen bestimmter Datenbankobjekte, realisiert: Die Eigenschaften des Objekts werden im WWW-Browser in einem HTML-Formular angezeigt, das bereits mit den Attributwerten des Objekts "ausgefüllt" ist. Durch Ändern der Einträge und Abschicken des Formulars können die Eigenschaften des Objekts manipuliert werden. Das Umsetzen des Smalltalk-Objekts in ein Formular und Rückübersetzen des Formulars in Smalltalk-Code wird vom PRISMA-Werkzeug SHIC (Smalltalk/HTML Interchange Compiler) geleistet.

Unterstützt wird die <berführung der Objekte z.B. in Formulare von den Objekten selbst. Die PRISMA-Wurzelklasse PrismaObjekt definiert eine Methode, welche die Eigenschaften des Objektes in eine programmiersprachenunabhängige Repräsentation übersetzt. In der momentanen Implementierung besteht sie aus einer Byte-Folge, die entsprechend der Syntax des PRISMA-Protokolls erzeugt wird. Diese Byte-Folge ist eine "linearisierte" Form der Objekte. Ein Header beschreibt die Anzahl und Position der "hintereinander" angeordneten Objektbestandteile. Die CGI-Programme "verstehen" das verwendete Protokoll, interpretieren die Byte-Folge und erzeugen ein Formular, z.B. zum Editieren. In einer späteren Implementierung sollen für die programmiersprachenunabhängige Repräsentation vorhandene Standards wie IDL verwendet werden. (Zur Zeit der Entwicklung des Prototyps stand die zur Implementierung der Standards benötigte kommerzielle Software noch nicht zur Verfügung.).

Ähnlich wie ein Objekt von sich selbst eine Repräsentation seiner Eigenschaften erzeugen kann, "weiß" es auch, wie es eine für einen WWW-Browser geeignete Darstellung von sich erzeugt. Dazu besitzt jede Klasse eine ihrem Aufbau entsprechende Darstellungsmethode. Diese erzeugt eine HTML-Repräsentation des Objektes. Ein Objekt der Klasse GIFAtom kann so unmittelbar in einem Browser angezeigt werden. Die dazu notwendigen Schritte werden von der Darstellungsmethode durchgeführt.

Auf die Art der Darstellung kann der KDBA Einfluß nehmen, und zwar nicht nur auf Klassenebene, sondern auch für einzelne Objekte. Konkret bedeutet dies, daß zwei Objekte der gleichen Klasse sich bezüglich der Art ihrer Darstellung unterscheiden können, indem das eine etwa die Standard-Voreinstellung der Darstellung (Default-Darstellung) der Klasse verwendet, für das andere Objekt aber vom KDBA eine individuelle Darstellungsart definiert wurde, die dann die Defaultmethode der Darstellung gewissermaßen "überschreibt". Das Erstellen von Dokumenten aus Datenbankobjekten wird dadurch äußerst flexibel.

Die Sprache zur Beschreibung der Darstellung ist in der momentanen Implementierung im wesentlichen HTML. Im Laufe der Weiterentwicklung des Systems soll davon aber weiter abstrahiert werden, um einerseits die Darstellungsbeschreibung noch zu vereinfachen und um andererseits die zu enge Bindung an HTML zu überwinden.


4.3.2. Die Beispielsitzung

Die Möglichkeiten und Funktionsweise von PRISMA wird am besten an einer "Beispielsitzung" verdeutlicht. Bildschirmschnappschüsse zeigen dabei die einzelnen Masken der Bedienoberfläche. Folgendes Szenario soll durchgespielt werden: Der KDBA will, ausgehend von den im System bereits vorhandenen Basisklassen, Dokumente zum Vergleich von Bildern der Künstler Gris und Picasso zusammenstellen. Er wird dazu die zwei neuen Klassen Kuenstler und Bild definieren, eine Reihe von Objekten zu diesen Klassen neu anlegen und verknüpfen sowie für bestimmte Objekte individuelle Darstellungen definieren.

Figur 12: Ausgangsmaske zum Bearbeiten von PRISMA-Objekten

Fig. 12 zeigt die Ausgangsmaske zum Bearbeiten von PRISMA-Objekten. Zur Durchführung der oben skizzierten Aufgabe müssen zunächst zwei neue Klassen angelegt werden. Der Administrator folgt dazu unter "Eingabe" dem Link "neue Klasse". Dieser Link verweist auf ein HTML-Dokument, in dem ein Klasseneingabeformular realisiert ist. Fig. 13 zeigt dieses Formular.

Figur 13: Das Klasseneingabeformular

Im Formular wählt der Administrator zunächst die Oberklasse der zu erzeugenden neuen Klasse. Im Falle des Beispiels ist das die Klasse DatenMolekuel. (Sie ist in der momentanen Implementierung die einzige Klasse, die als Oberklasse gewählt werden kann. Die Oberklassenwahl wurde dennoch als Auswahlliste realisiert, um in späteren Erweiterungen auch andere Klassen zuzulassen.) Indem die neue Klasse als Unterklasse von DatenMolekuel angelegt wird - und diese selbst eine Unterklasse der allgemeinen Klasse PrismaObjekt ist -, besitzt sie durch Vererbung bereits die typischen Eigenschaften einer PRISMA-Klasse, wie die Attribute "Name" und "Schlüsselwörter" sowie die Möglichkeit der Objekte, aus ihrem Zustand eine Protokoll-Byte-Folge zu erzeugen. Dies spielt, wie wir sehen werden, bei der Definition neuer Objekte ein Rolle.

Nach der "Auswahl" der Oberklasse wird der Name der neuen Klasse in das entsprechende Feld eingetragen. Der Name mufl eindeutig sein, d.h. es darf noch keine Klasse dieses Namens existieren, da sonst das Anlegen fehlschlägt (im Browser erscheint eine entsprechende Fehlermeldung).

Als nächstes gibt der Administrator die Namen der Attribute und Objektbeziehungen als kommagetrennte Liste in das dafür vorgesehene Formularfeld ein. Hier wird zunächst nicht zwischen Attribut und Objektbeziehung unterschieden; beide werden unter dem Begriff "Attribut" subsumiert. Beim Anlegen der Attribute sollte man zwei Dinge beachten: Erstens sollten die Namen der Attribute "sprechend" sein, d.h. sie sollten wie in obigem Beispiel etwas über den Typ des späteren Wertes aussagen. Zweitens sollte die Anzahl der benötigten Attribute beim Anlegen der Klasse bereits feststehen. Das spätere Hinzufügen bzw. Entfernen von Objekteigenschaften ist zwar unter der von uns verwendeten Datenbank möglich, aber mit Umständen und Risiken verbunden.

Nach Abschicken des Formulars versucht PRISMA, die neue Klasse in der Datenbank anzulegen. Dazu schickt der Browser das "ausgefüllte" Formular mittels HTTP an den Server. Dort angekommen wird das zur Auswertung benötigte CGI-Programm (dessen Name ebenfalls im Formular angegeben ist und im Fall des obigen Beispiels im zugehörigen HTML-Dokument codiert ist) aufgerufen. Dieses Programm liest die Werte aus dem Formular aus und "baut" daraus eine Anweisung zum Erzeugen einer neuen Klasse in der Datenbank. Eine solche Anweisung wird in Form eines PRISMA-Protokoll-Strings an die PRISMA-Datenbank, konkret an die Smalltalk-Schnittstelle von Versant übermittelt. Auf der Datenbankseite wird die Anweisung dekodiert und ausgeführt. Im Fall, dafl die Anweisung erfolgreich ausgeführt werden konnte, wird in umgekehrter Richtung eine Bestätigung, ansonsten eine Fehlermeldung zum Browser zurückgeliefert und der Administrator über Erfolg oder Miflerfolg seiner Aktion informiert.

Fig. 14 veranschaulicht den internen Ablauf beim Anlegen einer Klasse. Das hier gezeigte Zusammenspiel der einzelnen Softwaremodule ist typisch für alle PRISMA-Aktionen, die aus einem WWW-Browser heraus durchgeführt werden.

Figur 14: Der interne Ablauf beim Anlegen einer neuen Klasse

Für das Beispiel nehmen wir natürlich an, daß unsere Bemühungen von Erfolg gekrönt waren und erzeugen gleich anschließend auf die gleiche Weise die Klasse Kuenstler mit den Attributen Name, Vorname, Portrait, Geburtsort, Geburtsdatum, Sterbeort und Sterbedatum.

Klassen sind nur Datenschablonen. Die eigentlichen "Datenträger" sind die Objekte, die Exemplare der Klassen. Als nächsten Schritt wollen wir daher zu den gerade erzeugten Klassen die benötigten Objekte erzeugen. Im Falle der Klasse Kuenstler sind das die Objekte "Picasso" und "Gris". Das Anlegen von Objekten wird nur an einem Beispiel gezeigt, da dieser Vorgang für alle neu anzulegenden Objekte analog abläuft.

Zum Anlegen eines neuen Objekts wählt der Administrator unter "Bearbeiten" den Link "Klassen" (s. Fig. 12). Das System antwortet, wie in Fig. 15, mit einem HTML-Dokument, das in einer Tabelle die bearbeitbaren Datenbankklassen anzeigt.

Figur 15: Auswahlmaske zum Bearbeiten von Klassen

Im Falle des Beispiels sind das die neu angelegten Klassen Bild und Kuenstler. Zu jeder Klasse existieren die Schaltflächen "Neu" und "Darstellung". Anklicken von "Neu" erzeugt ein Formular zum Anlegen eines neuen Exemplars der entsprechenden Klasse, wie es in Fig. 16 zu sehen ist.

Für jedes Attribut des neuen Objekts zeigt das Formular ein Eingabefeld, das mit dem Namen des Attributs überschrieben ist. Unter jedem Eingabefeld befindet sich auflerdem eine Reihe von Auswahlknöpfen, über die der Administrator Angaben zum Typ des Attributwertes macht. Die Voreinstellung ist String. Durch Ändern der Voreinstellung wird der eingetragene Wert entsprechend interpretiert und, falls möglich, in den gewünschten Typ umgewandelt.

Neben den Auswahlknöpfen existiert auflerdem ein Optionsknopf Liste.Durch Aktivieren dieser Option wird aus dem/den eingetragenen Wert(en) eine Kollektion erzeugt. Zwei oder mehr Werte werden dabei, wie bereits bei der Angaben von Attributen, als kommagetrennte Liste angegeben. Eine Kollektion der Vornamen Jose, Victoriano, Carmelo und Carlos erzeugt man z.B. durch Eingaben von "Jose, Victoriano, Carmelo, Carlos" und Auswahl des Typs String sowie der Option Liste.

Figur 16: Ausschnitt aus dem Formular zum Anlegen eines Exemplars der Klasse Kuenstler

Objektbeziehungen können ebenfalls über dieses Eingabeformular geknüpft werden. Hier mufl man derzeit noch den unbequemen und wenig inituitiven Weg über die Objekt-Id wählen. Konkret trägt man dazu die Id des Objektes, das referenziert werden soll, in das Eingabefeld ein und wählt Objekt als Typ. Sollen mehrere Objekte, also eine Kollektion von Objekten referenziert werden, so kann dies auch in diesem Fall mit Hilfe der Option Liste erreicht werden. Bleibt die Frage: Woher bekommt man die benötigte Objekt-Id? Auf diesen Punkt wird später eingegangen.

Durch Ausfüllen eines Formulars wie in Fig. 16 erzeugt der Administrator nun die beiden Kuenstler-Objekte "Picasso" und "Gris". Wählt er in der Maske aus Fig. 15 "Bild" statt "Kuenstler", so wird ein der Fig. 16 ähnliches Formular zum Anlegen neuer Bild-Objekte erzeugt. Ein wesentliches Attribut eines Bildes ist die Abbildung, also die GIF- oder JPEG-Graphik. Objekte dieses Typs sind PRISMA-Exemplare der Klassen GIFAtom oder JPEGAtom.. Diese elementaren Bausteine können im allgemeinen nicht über ein Eingabefeld in die Datenbank eingetragen werden. PRISMA verfügt daher über ein Formular mit dessen Hilfe Objekte solchen Typs, nämlich allgemeiner Unterklassen der PRISMA-Klasse DatenAtom, von einem externen Datenträger (Festplatte oder Diskette) in die Datenbank eingelesen werden können. Dieses Formular benutzt ein Formular-Feld vom Typ file, das es erlaubt, Dateien auf dem Rechner, auf dem der WWW-Browser läuft, zu suchen und an den Server zu übermitteln. Mit Hilfe dieser Eigenschaft, die allerdings z.Z. noch nicht von allen Browsern unterstützt wird, können Daten beliebigen Typs vom Client über http auf den Server übertragen werden. PRISMA benutzt sie, um (u.a.) Graphikdaten von externen Datenträgern in die Datenbank einzulesen. Fig. 17 zeigt das entsprechende Formular.

Figur 17: Formular zum Einfügen neuer DatenAtome in die Datenbank

Obligatorisch ist neben der Auswahl eines Datenfiles die Angabe eines Namens sowie von Schlüsselwörtern. Eine eingehendere Beschreibung des neu anzulegenden Atoms ist dagegen optional. Das Formular bietet auflerdem die Möglichkeit, das Atom gleich einer Kollektion hinzuzufügen. Aus organisatorischen Gründen kann es sinnvoll sein, etwa eine Kollektion GrisBilder anzulegen, die alle GIF- bzw. JPEG-Graphiken von Bildern des Künstlers Gris zusammenfaßt. Neue Kollektionen können in einem eigenen Formular erzeugt werden. Durch Abschicken der Formulars werden die Graphikdaten vom externen Datenträger geladen und zusammen mit den angegebenen Attributwerten an die Datenbank übertragen, wo ein entsprechendes Objekt angelegt wird. Neben dem unmittelbaren <bertragen an die Datenbank bietet das Formular die Möglichkeit, sich die Datei zuerst anzusehen, um zu überprüfen, ob man die richtige Datei ausgewählt hat. Auf diese Weise kann der Administrator alle benötigten Graphiken von Gris und Picasso, die auf externen Datenträgern vorliegen, in die Datenbank einfügen.

Der Administrator kann jetzt neue Bild-Objekte erzeugen, wobei neben den textuell einzugebenden Attributwerten auch dem Attribut Abbildung als Wert eine Referenz auf ein GIFAtom-Objekt zuweisen. Dazu benötigt er die Objekt-Id des gewünschten GIFAtoms. PRISMA zeigt daher neben dem Namen des Objektes auch seine Objekt-Id an und unter Verwendung von sogenannten Frames ist es möglich, ein Eingabeformular und eine Auflistung von Objekten, beispielsweise den Inhalt der Kollektion GrisBilder nebeneinander im Browser darzustellen. Eine solche Liste erhält man z.B. durch Auswählen des Links "Collections" unter "Bearbeiten", vgl. Fig. 18.

Bild

Figur 18: Objektliste und Eingabeformular ermöglichen das Erstellen von Objektbeziehungen.

Das Bild-Objekt Bäuerin wurde auf die oben beschriebene Weise angelegt. Damit das Objekt im WWW-Browser angezeigt werden kann, muß man für die Klasse Bild eine Default-Darstellungsmethode definieren. Man wählt dazu unter "Bearbeiten" den Link "Klassen" und erhält das in Fig. 15 gezeigte Formular. Wählt man statt "Neu" nun "Darstellung", so antwortet PRISMA mit einem Formular wie in Fig. 19.

Bild

Figur 19: Formular zum Festlegen der Default-Darstellungsmethode für eine Klasse

Die Darstellungsmethode wird in einem leicht modifizierten HTML-Code angegeben. Dabei verwendet man die Attributnamen als Platzhalter[18]. Bei der Darstellung eines Objektes der Klasse werden diese Platzhalter durch die aktuellen Attributwerte ersetzt. Auflerdem kann man Attribute, die keine Wert besitzen, aus der Darstellung ausblenden. Auf die Syntax soll hier nicht weiter eingegangen werden, da dieser Teil von PRISMA noch erheblich komfortabler gestaltet werden soll und daher noch Änderungen zu erwarten sind. Mit oben eingetragener Darstellung zeigt sich das Bild "Bäuerin" wie in Fig. 20 gezeigt.

Die eigentliche Abbildung, das GIFAtom, ist in der Darstellungsmethode als Image (<IMG SRC=@abbildung@>) angegeben und wird, obwohl es ein von dem Bild "Bäuerin" verschiedenes Objekt ist, direkt angezeigt. PRISMA baut hier aus unterschiedlichen Datenbankobjekten ein Dokument. Die Referenz auf das Kuenstler-Objekt ist als Link modelliert (<A HREF=@kuenstler@>Der Künstler</A>). Folgt man diesem, so wird das im Attribut Kuenstler referenzierte Datenbankobjekt nach der für dieses Objekt bzw. seine Klasse angebenen Darstellungsmethode angezeigt.

Bild

Figur 20: Das Bild-Objekt "Bäuerin"

in Default-Darstellung

Wir wollen nun für die "Bäuerin" eine individuelle Darstellungsmethode definieren. Dazu wählen wir unter "Bearbeiten" den Link "Objekte nach Klassen" und aus der Liste der Klassen die Klasse Bild. Daraufhin erzeugt PRISMA eine Liste von Objekten wie in Fig. 21.

Bild

Figur 21: Maske zum Bearbeiten von Objekten der Klasse Bild

Bild

Figur 22: Editierformular mit neuer Darstellungsmethode für das Bild-Objekt Bäuerin

In der Zeile "Bäuerin" wählen wir die Schaltfläche "Ändern" und erhalten ein Formular ähnlich dem in Fig. 16. Nun allerdings sind die Textfelder nicht leer, sondern mit den aktuellen Attributwerten belegt. Alle angezeigten Attribute können hier editiert werden. Durch Abschicken des Formulars wird das Datenbankobjekt entsprechend den vorgenommen Änderungen angepaßt. Außer den Attributwerten kann man in einem solchen Formular auch die individuelle Darstellung des Objekts eingeben bzw. editieren.

Fig. 22 zeigt das Formular, in dem bereits die neue Darstellungsmethode eingetragen ist. Die Objektreferenz auf die Abbildung ist ebenso wie die auf das Kuenstler-Objekt nun als Link realisiert (<A HREF=@abbildung@>@name@</A> bzw. <A HREF= @kuenstler@> Juan Gris</A>). Die übrigen Attribute werden nicht mehr berücksichtigt. Das Bild-Objekt Bäuerin präsentiert sich nun in einer einzigen Zeile, also ohne Graphik, wie Fig. 23 zeigt.

Bild

Figur 23: Das Bild-Objekt Bäuerin in neuer Darstellung.

In dieser Beispielsitzung haben wir die wesentlichen Funktionalitäten der aktuellen PRISMA-Implementierung vorgestellt. Dabei wurde in erster Linie auf die Nutzungsmöglichkeiten als ein Autorensytem eingegangen. Die Recherchefunktionalitäten, wie sie einem nichtadministrativen Benutzer zur Verfügung stehen, sind lediglich eine Untermenge der Möglichkeiten des KDBA. Der Benutzer kann einzig Informationen abrufen, nicht aber Objekte verändern.

PRISMA ist work in progress, die momentane Implementierung ist ein Prototyp, in dem bisher lediglich ein Teil unserer Ideen realisiert wurde. Die bisherigen Ausführungen können daher auch nur einen ersten Eindruck geben, sollen gleichzeitig aber auch aufzeigen, welches Potential in der Verknüpfung von Datenbanktechnologie, inbesondere objektorientierter, mit der innovativen Technologie des WWW steckt.


5. Evaluation der bisherigen Projektpräsentationen

Das PRISMA-Projekt präsentierte sich vom 02. bis 07. Oktober 1996 auf der 43. Frankfurter Buchmesse sowie am 09. Oktober 1996 auf der Präsentation des Forschungsverbundes Medientechnik Südwest (FMS) in Stuttgart. Außerdem wurde das Projekt bereits am 28. September 1996 im Rahmen eines Workshops beim 1st International Symposium on Decision Support in Anaesthesia and Intensive Care an der Johannes Gutenberg-Universität Mainz vorgestellt.


5.1. Der Aufbau des präsentierten Systems

Auf der Frankfurter Buchmesse und der Präsentation des FMS wurde das PRISMA-Informationssystem als lokale Netzwerkinstallation vorgestellt, da aus organisatorischen Gründen kein direkter Anschluß ans Internet möglich war. Die Datenbank Versant war auf einer Unix-Sparc 10-Workstation mit 96 MB Arbeitsspeicher unter dem Betriebssystem Sun Solaris 2.4 installiert. Dieser Rechner war über Ethernet mit einem Apple Macintosh Quadra 950 verbunden, die Korrespondenz der Rechner erfolgte über Helios Netzwerksoftware. Auf dem Unix-Rechner wurde ein NSCA 1.4.2-WWW-Server betrieben, der eine Benutzung der entwickelten WWW-Schnittstelle der Datenbank sowohl von der Unix-Plattform wie auch über den angeschlossenen Macintosh-Rechner ermöglichte. Als WWW-Browser wurde auf beiden Geräten der Netscape Navigator 3.0 verwendet.

Auf der Buchmesse war über Ethernet zusätzlich eine Efi Fiery IPU angeschlossen, die es erlaubte, einen Kodak Farblaserkopierer 1560 als Scanner sowie als Ausgabemedium zu benutzen. Zum Vorführen von gespeicherten Tondateien war der Macintosh Quadra 950 mit einem Audioverstärker gekoppelt.


5.2. Schwerpunkte der Präsentation

Zum Zeitpunkt der Messepräsentation lief die Entwicklung und Implementation der benötigten Software erst etwa ein halbes Jahr. Daher war die Gesamtanlage des Informationssystems naturgemäß nicht komplett verfügbar. In einer ersten Implementation wurden auf der Frankfurter Buchmesse und dem FMS-Projekttag die folgenden Schwerpunkte vorgestellt:


5.2.1. Die WWW-Schnittstelle des Informationssystems

Eine der Hauptforderungen für die Funktionalität des Informationssystems ist, wie bereits erwähnt, die Verfügbarkeit der angeschlossenen Datenbanken über den Internetdienst WWW. Durch eine solche Anbindung werden die im Datenkern des Informationssystems gespeicherten Daten für die Zugangsberechtigten über graphische WWW-Browser erreichbar. Zusätzliche Softwarebeschaffung auf Seiten der Benutzer entfällt und wegen der Verwendung gültiger Standarddatenformate ist er auch weitgehend frei in der Wahl der eingesetzten Hardware. Die Informationen dieses Systems sind also grundsätzlich für "jedermann" erreichbar.

Eine weitere bereits erwähnte Forderung bestand darin, Datenbankfunktionen, wie z.B. Neueingabe, Änderung oder Löschung von Daten, zu ermöglichen und auf einer intuitiven, benutzerfreundlichen Oberfläche im WWW-Browser darzustellen. Die Werkzeuge für diese einfachen Datenbankoperationen konnten während der Präsentation vorgeführt und getestet werden. Sie erwiesen sich als stabil, auch bei der Behandlung unterschiedlicher Datenformate[19]. Da die Bedienung der Datenbank auf gängige Funktionen von WWW-Browsern adaptiert wurde und bei der Mehrzahl der Besucher bereits Fertigkeiten im Umgang mit dem Internet/WWW vorhanden waren, wirkte die Benutzeroberfläche des Informationssystems nach kurzer Einweisung in grundsätzliche Operationen meist selbsterklärend[20]. Das Interesse an komplexeren Datenbankoperationen, wie etwa gezielte Rechercheoptionen, war groß. Diese Funktionen werden allerdings erst in einer späteren Projektphase entwickelt, in der eine deutliche Trennung der globalen Benutzeroberfläche und derjenigen der zugelassenen Datenbankbenutzer erfolgt, und standen während der Präsentation noch nicht zur Verfügung.


5.2.2. Multimedia-Funktionen

Das PRISMA-Informationssystem ist mit Hilfe eines graphischen WWW-Browsers via Internet abfragbar. Die graphischen Fähigkeiten der gängigen WWW-Browser werden permanent erweitert und die Palette der standardisierten Austauschformate für Daten nimmt ebenfalls zu. Der Austausch reiner Textdateien über das Internet ist heute bereits die Ausnahme. Nahezu jede Seite ist mit graphischen Erweiterungen wie Hintergrundgraphik, (zum Teil animierten) Bildern und graphischen Bedienelementen ausgestattet. Das wenig determinierte Schlagwort Multimedia umfaßt Bereiche wie z.B. Text-, Audio-, Grafik-, Video-, Animations-, CAD/CAM- und 3D-Daten, eben das Spektrum dessen, was die derzeit auf dem Markt erhältlichen PCs darzustellen vermögen. Daten dieser Art sind bereits auf dem Internet zu erreichen und ein Datenbanksystem, das im Internet arbeiten soll, muß sich zur Verarbeitung solcher Daten bereits jetzt eignen.

Das PRISMA-Informationssystem zeigte zunächst an einigen Standardformaten (HTML, GIF, JPEG, MIDI) seine Funktionalität in dieser Hinsicht. Andere Formate, vor allem für Audiodaten und Animationen, sind für die nächste Zukunft vorgesehen. Besonders diese Fähigkeit des Informationssystems stieß bei den Messebesuchern auf großes Interesse. Bei einigen Datenbankbetreibern, Museen, Sammlungen und Archiven, besteht Bedarf daran, die Kerndaten ihrer Datenbanken zum Teil um Bildmaterial bzw. um Audiodaten zu erweitern und ihre Systeme für das WWW erreichbar zu machen[21].


5.2.3. Die Optionen des Autorensystems

Auffällig war das Interesse der Besucher an der Option, die Ausgabe der Daten über das WWW durch selbstdefinierte Darstellungen dieser Daten zu verändern. Der Administrator der Datenbank kann die Darstellung von Daten selbst definieren, indem er sie in gesonderten HTML-Code einbettet, bevor sie an den Browser des Benutzers ausgegeben werden. Diese Darstellung läßt sich für einzelne Datenbankobjekte, für ganze Klassen oder Mengen ausgewählter Daten definieren. Eine solche Art der Datenaufbereitung ist erst durch die objektorientierte Struktur des Informationssystems möglich und bildet zusammen mit der graphischen Oberfläche des WWW-Browsers, in dem die Datenbankausgabe abgebildet wird, ein neue Möglichkeit zur Informationsdarstellung, die das Leistungsvermögen herkömmlicher Datenbanken übersteigt.


5.2.4. Bemerkungen zur Verarbeitungsgeschwindigkeit

Die überwiegende Mehrheit der Ausstellungsbesucher auf der Buchmesse waren Bibliothekare, die üblicherweise an relationalen bzw. hierarchischen Bibliotheksdatenbanken arbeiten. In diesen Datenbanken werden reine Texteingaben verarbeitet, die Datenbanken selbst sind auf PCs eingerichtet und arbeiten oft unter dem Betriebssystem MS-DOS. Die Verarbeitung der für diese Datenbanken typischen festen Datensätze erfolgt auf den für eine solche Anwendung optimierten kommerziellen Systemen sehr schnell, zumal die Darstellung für die Benutzeroberfläche der Anwendung entsprechend sehr einfach gehalten ist und der Zugriff lokal erfolgt.

Die Benutzeroberfläche des PRISMA-Informationssystems wird in einem graphischen Browser dargestellt, benötigt also eine graphische Oberfläche wie z.B. Windows, MacOS, X-Windows usw. Der Bildschirmaufbau einer solchen Oberfläche beansprucht Systemressourcen des jeweiligen Rechners, eine Darstellung von Daten in einer solchen Umgebung ist systembedingt langsamer als eine nichtgraphische Anwendung. Die größte Verzögerung beim Datentransport innerhalb des Informationssystems entsteht allerdings durch die Übertragung der Daten über das Internet. Hier wirken sich nicht nur die derzeit herrschenden Leitungsengpässe auf die Übertragung von PRISMA-Daten aus. Auch der über Ethernet realisierte Übertragungsweg von der Datenbank an einen WWW-Server und von diesem an den WWW-Browser des Benutzers dauert länger als der Direktzugriff auf eine oben beschriebene Datenbank.


5.3. Zusammenfassung

Das PRISMA-Informationssystem ist nicht notwendigerweise für eine konkrete Anwendung spezifiziert. Die Implementierung als kunstwissenschaftliche Anwendung dient lediglich Testzwecken. Die Besucher der Messe waren zunächst durch diese konkrete Anwendung irritiert, zeigten aber nach kurzer Einweisung Interesse an dem System, da dessen freies Konzept Möglichkeiten zu einer spezifischen Adaption in anderen Bereichen aufzeigen konnte. Hierbei ist generell gleichgültig, ob das System im Intranet, also innerhalb des Netzwerksystems einer Firma, oder im Internet als Verwaltungsebene für weiträumig verteilte Datenbanken installiert wird. Konkret wurden von Besuchern folgende Verwendungsmöglichkeiten angedacht:


6. Ausblick - Nutzungsmöglichkeiten des PRISMA-Systems

6.1. Reduzierung der Netzauslastung

Mit permanent ansteigender Nutzung der Netzwerkdienste im WWW durch kommerzielle Anbieter und öffentliche Einrichtungen wird die Internetverbindung zwischen Datenanbieter und Anwender zu einer knappen Ressource, da die zur Verfügung stehenden Übertragungswege zunehmend ausgelastet werden. Der Zugang zu gesuchten Informationen wird in dem Maße schwieriger, wie das Datenangebot auf dem Netz zunimmt. Ein Kollaps dieser Entwicklung ist langfristig nur durch einen Ausbau der Infrastruktur, also etwa der Leistungssteigerung der Übertragungsleitungen zu erreichen. Eine Beschleunigung in der Datenübertragung ist zwar durch verstärkten Einsatz von Glasfaserkabeln schon in den nächsten Jahren zu erwarten, die momentan in Spitzenzeiten auftretenden Probleme in der Datenübertragung bei voller Netzauslastung und damit verbundene lange Wartezeiten sind aber ein akutes Problem, das sich zunächst nur noch weiter verschärft.

Eine kurz- bzw. mittelfristige Entlastung in dieser Situation könnte durch eine Optimierung des Datentransportes erzielt werden. Dazu gehört das Vernetzen verschiedener Datenträger über Recherchesysteme innerhalb von Informationssystemen. Mehrfache Datenhaltung, und damit verbunden auch mehrfacher Transfer identischer und damit redundanter Daten an einen "Datensuchenden", kann durch solche Systeme verhindert werden.


6.2. Allgemeine Recherche

Daten werden von unterschiedlichen Anbietern zu den verschiedensten Themen angeboten, für den potentiellen Nutzer sind sie aber nur schwer gezielt zu finden. Ein ausbaubares, themenbezogenes Informationssystem kann hier eine Brücke schlagen.

Eine Vernetzung verteilter Daten zu einem Informationssystem ist durch eine Verbindung von OODB[22] möglich. Über die Benutzerschnittstellen solcher Informationssysteme können unterschiedlichste Datenformate plattformübergreifend überall zugänglich gemacht werden. Über Informationssysteme kann eine wirksame und effiziente Plattform zum Wissensaustausch innerhalb des WWW entstehen.

Das WWW ist für seinen Nutzer ein schnell zugängliches Medium. Seine Popularität ist nicht zuletzt darauf zurückzuführen, daß der Zugang zu den gesuchten Daten über WWW-Browser keine aufwendige Schulung voraussetzt. Bei entsprechender Pflege und Aktualisierung von Daten kann z.B. im Bereich der Bibliographien über ein Informationssystem zielgerichteter gearbeitet werden als durch das bisher übliche Durchsuchen von Bibliothekskatalogen. Einige Bibliotheken präsentieren Teile ihres Angebots bereits jetzt über WWW. In Verbindung mit einem Informationssystem könnten Bibliographien, Biographien, Daten, Bilder etc. thematisch aufbereitet und aktualisiert werden und wären schnell verfügbar, sofern sie in Datenbanken erfaßt sind[23]. Der Einsatz von Informationssystemen in der Art des PRISMA-Informationssystems ist für abgegrenzte Themenbereiche sinnvoll, da die Ausgabe von redundanten Daten vermieden wird. Auch die Aktualisierung von Daten kann hier unter den verteilten Schnittstellen schneller erfolgen als auf herkömmlichen Suchmaschinen. Die Daten aus Informationssystemen sind von höherer Qualität als die Rechercheergebnisse von Suchmaschinen, da die Bestände von Datenbanken direkt abgefragt werden können, während Suchmaschinen lediglich die Adressen von Datenbanken auffinden können.


6.3. Forschung

Für den Bereich der Forschung kann ein über WWW erreichbares Informationssystem mit Anschluß auch an andere Datenbanken ein Forum zur Information, zum wissenschaftlichen Austausch und zur Projektkoordination werden. Zum Teil werden Optionen der Internetdienste, wenn auch sehr einfach, in Form von Telnet, E-Mail und FTP bereits lange genutzt. Eine graphische Oberfläche, wie sie heute jeder PC darstellen kann, bietet aber besonders im Bereich der Bild- und Tonwiedergabe weiterreichende Möglichkeiten.

Die Option zu Datenbankabfragen oder eine reine Präsentation der Forschungsergebnisse mittels HTML-Seiten, in denen audiovisuelle und textuelle Daten zusammen ausgegeben werden können, bieten neue Darstellungsmöglichkeiten, die von herkömmlichen Publikationsmedien nicht geleistet werden. Neue Wege der wissenschaftlichen Veröffentlichung lassen sich hier erahnen.

Besonderen Wert erhält ein solches Informationssystem durch Zusammenarbeit mit Archiven, Museen und Sammlungen. Hier könnten nach und nach Archivdaten zugänglich gemacht werden, was im Bereich der Forschung von großem wissenschaftlichem Nutzen wäre.


6.4. Erwachsenenbildung

Das WWW wird zunehmend auch zu einem Feld der Erwachsenenbildung. Durch das ständige Anwachsen multimedialer Anwendungen wird das Fachbuch durch Edutainment-Programme abgelöst bzw. ergänzt. Ein fachlich betreutes Informationssystem kann ein Schritt zur Erweiterung des Angebots auf dem Bildungssektor werden, wenn medienpädagogische Erkenntnisse und die Gestaltungsmöglichkeiten der Benutzerschnittstellen in Übereinstimmung gebracht werden. Auch in bisher wenig vom Computer erreichten Gebieten wie z.B. der Museumspädagogik kann die Möglichkeit des Internetzugangs zu Multimediadaten neue Darstellungsmethoden bewirken.


6.5. Computerunterstützter Unterricht

In den Schulen wird seit Jahren der Computereinsatz im Schulunterricht, vor allem auch in den nichtmathematischen Fächern, erprobt. In einigen Fächern erwies sich das Hilfsmittel Computer bisher als wenig brauchbar. Zum einen lag dies daran, daß für den Unterrichtseinsatz eine aufwendige Ausstattung an Hardware vonnöten war, zum anderen fehlte den Lehrkräften die Ausbildung im Umgang mit dem Computer und damit auch die Möglichkeit, den Nutzen dieses Hilfsmittels für ihr Unterrichtsfach zu bewerten. Für den Einsatz im Unterricht, vor allem in der Mittel- und Oberstufe, könnte ein über WWW leicht erreichbares erweiterbares Informationssystem unter fachlich betreuter Vorbereitung eine hilfreiche Erweiterung des Unterrichtsangebots darstellen. Gerade der Bereich der Multimediadaten kann für eine Anwendung im theoretischen Unterricht interessant werden.


6.6. Schwierigkeiten

Innerhalb von Forschungsprojekten ist es möglich, kommerzielle Aspekte einer Anwendung zunächst zu vernachlässigen und die innovativen Bereiche einer Aufgabe zuerst zu erforschen und auszubauen. Bei dem Gedanken an eine weitere Verwendung solcher Informationssysteme vom Typ PRISMA im Internet ist es jedoch unumgänglich, zwei Aspekte in der Frage der Informationsverbreitung zu berücksichtigen. Als erstes stellt sich schnell die Frage des Datenschutzes, der Datensicherheit der angeschlossenen Datenbanken und das auch mit Blick auf die Frage der Vervielfältigungs- und Verwertungsrechte an Bildern bei deren Verfügbarkeit über das WWW[24].

Ein zweiter wichtiger Aspekt, nicht weit vom ersten entfernt und ebenfalls international diskutiert, ist die Frage nach Möglichkeiten zur verschlüsselten Übertragung sensibler Daten. Auch wenn hier momentan die Sicherheitsbedürfnisse öffentlicher und kommerzieller Einrichtungen wie von Banken, Online-Versandhäusern, Kliniken usw. und die Bedenken von Strafverfolgungsbehörden und Sicherheitsdiensten unvereinbar scheinen, muß diese Entwicklung mit Blick auf eine erweiterte Funktionalität des Informationssystems und den denkbaren Einsatz in der Praxis verfolgt und berücksichtigt werden, auch dann, wenn diese Überlegungen außerhalb der formulierten Projektziele liegen.


7. Literatur

[1] Andleigh,P.K.;Gretzinger, M.R.

Distributed Object-Oriented Data-Systems Design.New Jersey, 1992.

[2] Benn, W.; Gringer, I.

Datenbank-Anwendungen über das Internet.

Chemnitzer Informatikberichte CSR 96-02, TU-Chemnitz-Zwickau, 1996

[3] Cattell, R.G.G. (Hrsg.)

The Object Database Standard: ODMG-93. San Francisco, 1994

[4] Dalitz, W.; Heyer, G.

Hyper-G. Das Internet-Informationssystem der 2. Generation. 1995

[5] Gundaravam, S.

CGI Programming. Bonn u.a., 1996.

[6] Himmelreich, B.

PARES - Ein Bildinformationssystem,

in: Objektspektrum, Nr 4/95, ISSN 0945 - 0491.

[7] Krimm, J.

Interpretation und Darstellung der Informationsstrukturen des WWW.

Diplomarbeit, Universität Mainz, erscheint 1997.

[8] Kroll, Ed.

The Whole Internet User's Guide & Catalog. Sebastopol, 1993.

[9] Lemay, Laura.

Web-Publishing mit HTML. München, 1995.

[10] Orfali, R./ Harkley, D./ Edwards, J.

The Essential Distributed Objects Survival Guide. New York u.a. (1996)

[11] Rieger, W.

SGML für die Praxis. Ansatz und Einsatz von ISO 8879. 1995

[12] Siegel, R.

CORBA Fundamentals and Programming. New York u.a.,1996

[13] Szillat, H.

SGML Eine praktische Einführung. 1995

[14] Tolksdorf, R.

Die Sprache des Web: HTML 3. 2. Aufl., Heidelberg 1996.



Anmerkungen

[1] Der zweitgrößte Internetdienst Compuserve beendete das 2. Geschäftsquartal 1996 mit ca. 30 Millionen Dollar Verlust. Grund hierfür ist wohl der Konkurrenzdruck unter den Internetprovidern und die damit gesunkenen Einnahmen aus Internetanschlüssen. (Macwelt 10/96, S.10).

[2] Diese Konsole ist nur eine Komponente einer "Produktfamilie für das Internet/Intranet" (Macwelt 4/96, S.12).

[3] Das erste deutsche Internet-Online-Radio sendet viermal täglich im Internet. (Macwelt 11/96, S.24).

[4] Eine solche Anwendung ist z.B. die WWW-Schnittstelle der Universitätsbibliothek an der Johannes Gutenberg-Universität Mainz. Hier sind Abfrageoptionen der Datenbank auf WWW-Seiten verfügbar.

[5] Hierbei handelt es sich um Softwarewerkzeuge, die bei den marktführenden WWW-Browsern als zuladbare Erweiterungen benutzt werden. So können Datenformate, die keinem WWW-Standard entsprechen, dennoch im Browser angezeigt werden. Diese Entwicklung ist zum einen nützlich, da hier für einen Datenanbieter die Möglichkeit besteht, komplexe Daten, z.B. Filme, in nur einem Datenformat anzubieten. Die Daten werden dann vom WWW-Browser auf Rechnern angezeigt, die ansonsten spezielle Hilfsprogramme verwenden müßten. Andererseits werden nun von vielen Softwareherstellern entsprechende Plug-Ins für ihre Datenformate angeboten, was zum einen den Speicherbedarf für die WWW-Browser der Anwender anwachsen läßt und zum anderen einer angestrebten Vereinheitlichung und Vereinfachung von Daten zugunsten einer plattformunabhängigen Kommunikation im WWW entgegenarbeitet.

[6] PARES ist der Arbeitsname des Teilvorhabens "Autodeskribierende Recherchesysteme" im Rahmen des vom Forschungsverbund Medientechnik Südwest (FMS) geförderten Projekts "Datenreduzierte digitale Speicherung von Musik und Sprache mit Echtzeitzugriff für Archive in Forschung und Rundfunk". Dieses Teilprojekt untersuchte die datenreduzierte Speicherung von regelbasierten Bildreihen an exemplarischen Bildanalysen aus dem Werk Picassos.

[7] Vgl. Abschnitt "Der Webmole - Ein Strukturierungswerkzeug für HTML-Konstrukte" im Kapitel "2.3.2. Die Versant-Verwaltungsebene".

[8] Im Bereich Musikinformatik der Johannes Gutenberg-Universität Mainz stehen für die Erprobung eines solchen Projektes die beiden objektorientierten Datenbanken GemStone und Versant zur Verfügung.

[9] Die Migration eines relationalen Datenbankschemas in das Informationssystem soll im Rahmen einer Diplomarbeit innerhalb des Projekts geleistet werden.

[10] HTML 2.0 ist als Standard für ein SGML-Dokument spezifiziert worden [14] (hier auch andere Spezifikationen).

[11] In den Bereichen der Audio-, Animations- und Videodaten greift das Konzept der Standardisierung von Datenformaten innerhalb des WWW nicht. Es gibt für unterschiedliche Rechnerplattformen unterschiedliche Datenformate. Der von der W3C vorgeschlagene Standard für Videodaten MPEG z.B. kann nicht auf allen Plattformen dargestellt werden. Filmdateien können auf PCs und Macintosh-Rechnern im Quicktime-Format abgespielt werden, Computer mit Unix-Betriebssystem dagegen können lediglich Filme im MPEG-Format darstellen.

[12] Die Firma Netscape z.B. führt einige Funktionen ihres WWW-Browsers "Navigator" als sogenannte HTML-Erweiterungen ein, bevor solche Konzepte dem W3C als Vorschläge für die Aufnahme in den HTML-Standard unterbreitet wurden.

[13] Zumindest für die Eingabe/Änderung von Daten ist diese Lösung komfortabler als die Alternative, für jede Einzeloperation ein eigenes Browserfenster zu öffnen.

[14] Dieses Werkzeug wird unter der Bezeichnung User Dependent Image Designer (UDID) im Rahmen einer Diplomarbeit innerhalb des Projekts erstellt.

[15] Hier bieten leistungsfähige WWW-Browser zwei Möglichkeiten zum Datentransport. Üblicherweise holt sich der Datensuchende komprimierte Dateien über HTTP bzw. FTP. Es gibt aber auch die Möglichkeit, dem Datensuchenden solche Dateien auf sein Verzeichnis zu übertragen, wenn die Zugriffsrechte dies zulassen.

[16] Die OMG (Object Managment Group) ist ein Zusammenschluß von Hardware- und Softwareherstellern, die sich schon frühzeitig um eine Standardisierung von Objekt-Technologien bemüht haben. Entwickler und Hersteller von objektorientierten Datenbanken bilden in der OMG eine Art Untergruppe, die Object Database Managment Group (ODMG). Sie betreibt speziell die Standardisierung von OODB-Technologien, insbesondere eines Objektmodells.

[17] Diese anschaulichen Begriffe dienen einer einfachen Darstellung. Das Konzept ist aber allgemeiner gehalten. Ähnlich wie in einem "Verzeichnis" bzw. "Dirctory" neben einfachen Dateien auch wieder Verzeichnisse selbst, in beliebiger Rekursion, enthalten sein können, kann ein "Datenmolekül" sich aus "Atomen", aber auch aus anderen "Molekülen" zusammensetzen.

[18] Diese Platzhalter bestehen aus den Attributnamen, die am Beginn und am Ende durch das Zeichen "@" markiert sind.

[19] Zur Demonstration der Datenbankfunktionalität wurden Text-, Audio- und Grafikdaten im Informationssystem eingelesen bzw. abgerufen.

[20] Ein Problem bildete die Festlegung auf eine bestimmte Sprache in der Ausgestaltung der Bedienoberfläche, da die deutschen und englischen Sprachkenntnisse einiger Besucher nicht zum Verständnis der Bedienfunktionen ausreichten. Eine multilinguale Lösung, wie sie für ein kommerzielles Produkt üblich wäre, ist wegen der geringen Personalkapazität des PRISMA-Projekts bei der Erstellung dieses Prototyps nicht zu leisten.

[21] Mitarbeiter des Deutschen Musikarchivs in Berlin beispielsweise sahen als Anwendung eines solchen Systems die Möglichkeit, kurze Klangbeispiele zu erfaßten Musikstücken über das Internet anzubieten.

[22] Die Möglichkeit zur Einbindung relationaler Datenbanken soll ebenfalls innerhalb des Projekts erprobt werden.

[23] Das Einbinden von "flüchtigen" Daten, also etwa Daten, die auf HTML-Seiten enthalten sind, ist auch für ein solches System eine personalintensive Aufgabe. Selbst wenn die Inhalte solcher Seiten automatisch strukturiert werden können, muß die Auswertung der Informationen auf ihre Brauchbarkeit durch einen kundigen Betreuer geleistet werden. Dieser Aufwand ist bei einer Auswertung von Datenbanken geringer.

[24] Derzeit gibt es nach Auskunft der Verwertungsgesellschaft für Bild und Kunst keine verbindlichen Richtlinien zum Erwerb von Vervielfältigungsrechten für Bilder, die im WWW präsentiert werden sollen. Hier fehlt es an internationalen Vereinbarungen.