PDF (Eine graphische Benutzerschnittstelle für ein Volltext-Retrieval ...

For: hemmje
Printed on: Fri, May 19, 1995 12:13:59
From book: LyberReport
Document: LTh_Titel
Last saved on: Fri, May 19, 1995 12:06:42
Document: LTh_Inhalt
Last saved on: Fri, May 19, 1995 12:06:42
Document: LTh_AbbVerz
Last saved on: Fri, May 19, 1995 12:06:42
Document: LTh_C1
Last saved on: Fri, May 19, 1995 12:06:42
Document: LTh_C2
Last saved on: Fri, May 19, 1995 12:06:43
Document: LTh_C3
Last saved on: Fri, May 19, 1995 12:06:44
Document: LTh_C32
Last saved on: Fri, May 19, 1995 12:06:48
Document: LTh_C34
Last saved on: Fri, May 19, 1995 12:06:48
Document: LTh_C35
Last saved on: Fri, May 19, 1995 12:06:50
Document: LTh_C41
Last saved on: Fri, May 19, 1995 12:06:51
Document: LTh_C42
Last saved on: Fri, May 19, 1995 12:06:52
( ...)

Angaben für Titelblatt der GMD-Studie:
Titel:
Eine graphische Benutzerschnittstelle
für ein Volltext Retrieval System
auf der Basis
interaktiver dreidimensionaler
Visualisierung
Autoren:
Matthias Hemmje
Clemens Kunkel
Alexander Willett
Erstellt bei:
Gesellschaft für Mathematik und Datenverarbeitung
(GMD)
Institut für integrierte Publikations- und Informationssysteme
(IPSI)
1

Zusammenfassung:
Die vorliegende Arbeit beschreibt die Grundlagen und die Entwicklung einer prototypischen
Benutzerschnittstelle (”LyberWorld”) für Volltext-Informationssysteme
auf der Basis dreidimensionaler räumlicher Visualisierungen. Die Arbeit wurde am
Institut für Intergrierte Publikations- und Informationssysteme (IPSI) der Gesellschaft
für Mathematik und Datenverarbeitung (GMD) in Darmstadt durchgeführt.
Die Entwicklungs und Implementierungsarbeiten wurden innerhalb der Abteilung
für Visuelle Interaktionswerkzeuge des Forschungsbereiches für Kognitive Benutzerschnittstellen
(CUI) innerhalb einer zweijährigen Studie von den Autoren
durchgeführt.
Das LyberWorld-System realisiert Visualisierungen eines abstrakten Informationsraumes
– Volltext. Innerhalb der vorliegenden Arbeit wird ein Modell zur Visualisierung
eines solchen Informationsraumes vom aktuellen Stand der Forschung ausgehend
abgeleitet. Die vorgestellte exemplarische Benutzerschnittstelle arbeitet auf
der Basis von INQUERY, einem probabilistischen Volltext-Retrieval System der
University of Massachusetts. Die vorgestellten Visualisierungen erlauben dem Benutzer
verschiedene direktmanipulative Aktivitäten wärend einer interaktiven Informationssuche
in großen Textmengen. Entsprechende Visualisierungswerkzeuge
ermöglichen ihm einen intuitiven Zugriff auf textuelle Informationen auf der Basis
von räumlichen Metaphern. In einer visuellen räumlichen Informationswelt befriedigt
der Benutzer sein Informationsbedürfnis mit Hilfe seiner natürlichen Fähigkeit
zur visuellen Wahrnehmung und Orientierung im Raum.
2

3

4

5

6

7

8

1. Einleitung und Motivation
”Ein Bild ersetzt 10.000 Worte”
Dieses chinesische Sprichwort verdeutlicht den hohen Wert von Bildern und graphischen
Darstellungen zur Vermittlung und Darstellung von Informationen.
Der Wert von Bildern wird besonders bei Lösungen und Präsentationen wissenschaftlicher
Probleme deutlich. In Disziplinen wie der Physik oder den Ingenieurwissenschaften
bedient man sich häufig einer graphischen Darstellung in Form von
Diagrammen, um Informationen schneller erfaßbar zu machen. Mit zweidimensionalen
Diagrammen lassen sich beispielsweise Beziehungen zwischen verschiedenen
Größen effektiver darstellen als durch eine textuelle Beschreibung [LARKIN87].
Bei einer graphischen Informationsdarstellung kann Information auf Attribute wie
Farbe, Form, Größe oder Position abgebildet werden. So lassen sich semantische
Beziehungen auf geometrische Abstände der Darstellung abbilden. Wichtigkeit von
Information läßt sich gut durch Größe oder Farbintensität der Darstellung codieren.
Eine solche Abbildung auf graphische Attribute ist intuitiv und somit schneller erfaßbar
als eine textuelle Beschreibung.
Graphische Benutzerschnittstellen
Die Vorteile einer graphischen Informationsdarstellung haben sich in den letzten
Jahren immer stärker auf die Gestaltung moderner Anwendungssoftware ausgewirkt.
Graphische Benutzerschnittstellen haben die Kommandooberflächen der ersten
Rechnergenerationen abgelöst. Bei graphischen Benutzerschnittstellen wird
der Vorteil der Informationsabbildung auf graphische Gegebenheiten nicht nur zur
Darstellung der dem Benutzer zu übermittelnden Informationen genutzt, sondern
auch zur Formulierung dessen Aktionen.
Die wohl meistverwendete Metapher für eine Benutzeroberfläche ist die einer
Schreibtischoberfläche. Auf dieser Oberfläche werden Objekte, die dem Benutzer
aus seiner ’natürlichen’ Arbeitsumgebung vertraut sind, plaziert. So können Dateien
durch Dokumente oder Akten, Verzeichnisse durch Ordner und verschiedene Blicke
auf die Arbeitsumgebung durch Fenster dargestellt werden. Der Benutzer braucht
seine Befehle nicht textuell einzugeben, sondern kann sie durch Aktionen wie Auswählen
oder Bewegen von Objekten der Oberfläche formulieren.
Das Löschen einer Datei geschieht beispielsweise nicht mehr durch Eingabe eines
Befehls, sondern durch das Auswählen und das anschließende Bewegen des Dateisymbols
auf das Symbol eines Papierkorbes.
Der Erfolg der fensterbasierten Benutzeroberflächen zeigt, daß es auch dem ungeübten
Benutzer möglich ist, sich in der an seine natürliche Umgebung angepaßten Arbeitsumgebung
zurechtzufinden.
Vorteile dreidimensionaler Darstellung
9

Diese Arten von zweidimensionalen Metaphern sind jedoch in ihrer Effektivität eingeschränkt,
da Darstellung und Benutzerinteraktion auf die Ebene beschränkt sind.
In einer räumlichen Darstellung fällt es dem Benutzer leichter, in der Umgebung zu
interagieren, da eine noch bessere Simulation der natürlichen Umgebung erreicht
werden kann und so Fähigkeiten wie Orientierung besser eingesetzt werden können.
Neben den graphischen Metaphern zur Definition von Benutzerschnittstellen sind
auch Modelle zur graphischen Darstellung abstrakter Informationsstrukturen meist
zweidimensional. Es gibt eine Vielzahl solcher Modelle, wie zum Beispiel Tabellen,
Graphen, Bäume und Netzwerke. Der Grund der Beschränkung auf zwei Dimensionen
mag zum einen, in der durch nicht rechnergestützte Arbeit erworbenen Gewohnheit
zu finden sein. Zum anderen sind erst die neuesten Rechnersysteme in der Lage,
bewegte dreidimensionale Graphiken ausreichend schnell zu generieren.
Die Entwicklung von Hard- und Softwaresystemen, welche die Möglichkeiten bieten,
sowohl statische, als auch animierte dreidimensionale Szenen mit hoher Qualität
zu visualisieren, hat die aktuelle Forschung veranlaßt, sich verstärkt auf das Design
dreidimensionaler Metaphern zu konzentrieren.
M. Hemmje diskutiert in [HEMMJE] die Vorteile einer Erweiterung der graphischen
Informationsdarstellung um die dritte Dimension und formuliert diese in folgenden
Hypothesen:
Im 3D-Raum kann Information über ein Element an einem Ort
lokalisiert werden; dadurch erübrigt sich die Verwendung symbolischer
Ausdrücke und die Suche nach ihnen.
Räumliche Darstellungen sind nicht deshalb besonders vorteilhaft,
weil sie potentiell mehr Information enthalten, sondern weil
die durch Anordnung im Raum möglichen Indexierungen der Information
die Informationsverarbeitungsprozesse des Menschen
effizient unterstützen
Darstellungen im 3D-Raum unterstützen intuitive Schlußfolgerungen
des Menschen, die für ihn unbewußt und damit ’einfach’
sind.
Für den Menschen stellt ein 3D-Raum einen natürlichen Bezugsrahmen
zur Verfügung, in den er sich einordnen kann. Anders als
beim 2D-Raum kann der Mensch sich selbst auf natürliche Weise
als Teil des Raumes empfinden und sich in diesem Raum lokalisieren.
Bei der Informationsvermittlung im Raum stehen durch Position,
Blickwinkel, Entfernung und Perspektive neue Parameter
(gegenüber 2D) zur Verfügung, die zu benutzerspezifischen
Parametern wie Standpunkt, Interesse oder Erfahrung in eine direkte
Beziehung gesetzt werden können.
Diffuses räumliches Erinnerungsvermögen mit Ahnungen wie
’das war dort hinten links irgendwo’ ist mit Hilfe von unscharfen
10

Abbildungen formulierbar. Dadurch kann eine Navigation mit
zunächst vagem Ziel im Raum oder in der Zeit (Dialoggeschichte)
unterstützt werden.
Eine dreidimensionale Benutzerschnittstelle
Mit der vorliegenden Arbeit wollen wir die Konzeption und Realisierung einer interaktiven
dreidimensionale Benutzerschnittstelle für ein vektorbasiertes Information-
Retrieval-System vorstellen. Die Benutzerschnittstelle stellt dem Benutzer Interaktionswerkzeuge
zur Führung des Retrievaldialogs und zur Auswertung, der aus der
Datenbank extrahierten Ergebnismenge, zur Verfügung.
Durch die Entwicklung einer dreidimensionalen graphischen Darstellung des Datenbankinhalts
ist es dem Benutzer möglich, in der abstrakten Datenstruktur zu navigieren.
Ziel einer Interaktion mit den Werkzeugen ist es, daß der Benutzer durch
intuitiv erlernbare Interaktionen, wie dem Navigieren in einer dreidimensionalen
Struktur den Information-Retrieval-Prozeß steuern kann.
Die Informationsvermittlung durch graphische Darstellung soll das Erlernen komplizierter
Datenbankanfragesprachen ersetzen.
In Kapitel 2 wird zunächst der Stand der Technik von Soft- und Hardwaresystemen
zur Graphikdarstellung und von graphischen Eingabegeräten beschrieben. Im Rahmen
der Beschreibung wird jeweils genauer auf die zur Realisierung des Prototyps
verwendete Soft- und Hardware eingegangen.
Kapitel 3 beinhaltet eine Beschreibung des Aufbaus verschiedener Information-Retrieval-Systemmodelle
und anschließend die Beschreibung von PUBLICAT, einem
traditionellen bibliographischen IR-System. Im Abschnitt 3.5. wird genauer auf das
Modell des vektorbasierten Information-Retrieval eingegangen. Mit dem Abschnitt
über das INQUERY-System folgt die Beschreibung des vektorbasierten IR-Systems,
auf dem die in dieser Arbeit vorgestellte interaktive 3D-Benutzerschnittstelle
aufsetzt.
Mit Kapitel 4 folgt nun eine umfassende Beschreibung der drei Interaktionswerkzeuge,
die die Benutzerschnittstelle bilden. Zunächst wird das Werkzeug zur Visualisierung
und Führung des Suchdialogs, der ’Kontextbaum’, vorgestellt. Zur Präsentation
der mit dem Kontextbaum erzeugten Ergebnismenge wird im folgenden
Abschnitt das Interaktionswerkzeug der ’Relevanzkugel’ definiert und zum Abschluß
folgt noch eine kurze Erläuterung des ’Dokumentenraumes’, mit welchem
der Inhalt der Elemente der Datenbank visualisiert werden kann.
In Kapitel 5 wird die Realisierung des Prototyps ‘LyberWorld’ beschrieben. Im ersten
Abschnitt des Kapitels wird anhand eines Beispielsuchvorgangs das Erscheinungsbild
und die Funktionalität des bestehenden Systems vorgestellt. Der zweite
Abschnitt beschäftigt sich mit der Realisierung des Systems als C++ Programm. An
dieser Stelle wird besonders auf die Klassenhierarchie und die wichtigsten Methoden
der einzelnen Klassen des Programms eingegangen. Den Abschluß des Kapitels
bilden einige Beispiele zur Erweiterung des Systems.
11

2. Stand der rechnergestützten 3D-Graphik
Dieses Kapitel bietet einen Überblick über die bestehenden Softwarenormen für
Graphik-Modellierungssysteme und den Stand der Technik der Graphikhardwaresysteme.
Desweiteren werden das verwendete Softwarepaket IRIS Inventor Toolkit
der Firma Silicon Graphics und die Architektur der verwendeten Graphikworkstations
der gleichen Firma genauer beschrieben. Im letzten Teil werden die Vorteile
multidimensionaler Eingabegeräte diskutiert.
2.1. Stand der Hardwaretechnik
Die frühen 50er Jahre werden von den meisten Autoren als Geburtsstunde der
Computergraphik angesehen [MACH78], [CACM84]. Eines der ersten Systeme das
Computergraphik zur Realisierung einer Mensch-Maschine-Schnittstelle nutzte,
war das ’SAGE air-defence-system’, welches Mitte der 50er Jahre entwickelt und
eingesetzt wurde.
Der Benutzer des SAGE–Systems saß vor einer radarschirmartigen Anzeige, welche
statt Punkten Symbole anzeigte, die der Benutzer mit Hilfe eines Lichtgriffels auswählen
konnte. Der Computer war außerdem in der Lage, Landkartenumrisse zu generieren
die dem Benutzer als Umgebung und Orientierungshilfe angezeigt wurden.
Der nächste Meilenstein in der Geschichte der Computergraphik war die Entwicklung
des ’Sketchpad’ von Ivan Sutherland, einem Doktoranten des MIT in den frühen
60er Jahren [SUTH63]. In den Arbeiten im Rahmen seiner Promotion definierte
Sutherland bereits graphische Primitive wie Linien, Polygone und Bögen, auf welche
Grundoperationen wie Translation, Rotation und Skalierung angewendet werden
konnten.
Diese Definitionen bildeten bereits das theoretische Fundament für später definierte
Graphiknormen, die im folgenden Kapitel 2.2. beschrieben sind.
2.1.1. Vektor- und Rastergraphik
Erst Ende der 50er und Anfang der 60er Jahre machten Forscher verschiedener Labors
(MIT, Universität Illinois) erste Versuche, eine Kathodenstrahlröhre (CRT =
Cathode Ray Tube) als Datensichtgerät zu verwenden. Die Kathodenstrahlröhre hat
sich seither trotz vieler neuer Technologien als meistangewandtes Ausgabegerät be-
12

hauptet. Gründe hierfür sind unter anderem die hohe Auflösung, die einfache Adressierung
und der niedrige Gerätepreis bei hoher Zuverlässigkeit.
Die Kathodenstrahlröhre wird sowohl in Vektor- als auch in Rastersichtgeräten eingesetzt
und bildet somit das Ausgabegerät fast aller Graphiksysteme.
Das Konzept der Vektorgraphik war die Basis der meisten frühen Graphiksysteme.
Bei einer Kathodenstrahlröhre zur Wiedergabe von Vektorgraphiken, wird wie bei
einem Oszilloskop der Elektronenstrahl auf den Kanten, aus denen das darzustellende
Objekt besteht, bewegt.
In einem Rastergraphiksystem wird das darzustellende Objekt aus einzelnen Bildpunkten
zusammengesetzt. Der Elektronenstrahl läuft in horizontalen Linien das
gesamte Bild ab und erhellt die Bildpunkte, aus denen das darzustellende Objekt besteht.
Der Vorteil der Vektordarstellung ist der wesentlich geringere Speicherbedarf zur
Speicherung eines Bildes. Während bei der Rasterdarstellung der Zustand jedes
Bildpunktes gespeichert werden muß, reicht es bei der Vektordarstellung aus, die
Eckpunktkoordinaten der darzustellenden Objekte zu speichern. Allerdings muß der
Vorteil des geringeren Speicherbedarfs mit einem wesentlich komplizierteren Elektronenstrahlablenksystem
in der Kathodenstrahlröhre bezahlt werden.
Mit der schnellen Entwicklung der Speicherbausteine durch die VLSI Technik und
dem damit verbundenen Preisverfall setzten sich die Rastergraphiksysteme durch.
2.1.2. Moderne Rastergraphiksysteme
Da die einzelnen Berechnungen, welche zur Darstellung von Rastergraphiken nötig
sind, leicht unterteilt werden können, nutzen moderne Graphiksysteme Parallelisierung,
um eine höhere Leistungsfähigkeit zu erreichen, d.h. die Teilberechnungen
werden auf verschiedene parallelarbeitende Prozessoren verteilt.[AKEL89]
Die Darstellungspipeline moderner geometriebasierter Rastergraphiksysteme läßt
sich in fünf fundamentale Schritte unterteilen:
1. Generierung G graphischer Daten und ihre Organisation
in Datenstrukturen
2. Traversierung T der Datenstrukturen und Berechnung der
Weltkoordinaten der Graphik
3. Transformation X in Bildschirmkoordinaten und
Ausführung von Clipping– und Shadingoperationen
4. Zeilenrasterung S (Scan Conversion) Beschreibung des
Rasterspeichers
5. Anzeige D (Display) Darstellung des Rasterspeicherinhalts
auf dem Bildschirm
13

Die Entwicklung moderner Graphiksysteme beinhaltet also weniger eine Entscheidung
ob Teilberechnungen auf verschiedene Graphikprozessoren verteilt werden,
sondern vielmehr wie eine solche Aufteilung realisiert wird. Entschieden werden
muß, welche der fünf Aufgaben speziellen Graphikprozessoren und welche den
Prozessoren der CPU übertragen werden.
Die Anzeige der Daten des Rasterspeichers auf dem Bildschirm variiert nicht zwischen
verschiedenen Graphikanwendungen, ist aber sehr zeitintensiv. Aus diesem
Grund wird sie in allen modernen Graphiksystemen einem speziellen Graphikprozessor
zugeordnet.
Auch bei der Realisierung der Generierung der Graphikdaten unterscheiden sich die
verschiedenen Graphiksysteme nicht, da diese Aufgabe aufgrund ihrer Komplexität
und der verschiedenen Variationsmöglichkeiten immer programmierbaren Prozessoren
übertragen wird.
Die für diese Arbeit verwendeten Graphikworkstations der Firma Silicon Graphics
sind mit einer GT–XSD Architektur realisiert, d.h. Die Generierung und Traversierung
der Graphikdaten wird mit programmierbaren Prozessoren realisiert, während
die restlichen drei Aufgaben speziellen Graphikprozessoren übertragen werden.
(Abbildung 1.1.)
Eine genauere Diskussion der Vor– und Nachteile der verschiedenen GTXSD Architekturen
findet man in [AKEL 89] und [FOLEY90].
14

G,T
memory
FPU
CPU
screen
R
G
B
geometry
engine
rendering
engine
frame
buffer
bit to video
converter
z–buffer
X S D
Architektur einer Silicon Graphics 4D/240GTX Worksta-
Abbildung: 1.1.
tion
2.2. Stand der Softwaretechnik
Die schnelle Entwicklung der Hardware im Bereich der Computergraphik führte in
den späten 70er und Anfang der 80er Jahre zu Standardisierungen im Softwarebereich.
Der erste Schritt auf dem Weg zu den heutigen Graphiknormen war die Veröffentlichung
des CORE-Systems im Jahre 1977. Mit CORE, einer Entwicklung des ACM/
SIGGRAPH Graphics Standards Planing Committee, lag eine erste Definition eines
portablen geräteunabhängigen Graphiksystems vor. Eine Graphik wird im CORE-
System aus graphischen Primitiven, welche mit Attributen versehen werden, erzeugt.
Ende 1982 wurde dann mit GKS das erste Graphikkernsystem als ANSI–Norm verabschiedet
[ENC88]. Die GKS-Norm definiert eine einheitliche Schnittstelle zwischen
Anwenderprogramm und Graphiksystem.
15

Abbildung 1.2. zeigt die Einordnung eines Kernsystems in die Systemhierarchie.
Das Anwendungsprogramm findet nur über die sprachabhängige Schicht den Kontakt
zum Kernsystem. Das Kernsystem ist folglich sprachunabhängig und muß in die
jeweils gewünschte Programmiersprache eingebettet werden. Da die gesamte Einund
Ausgabe über das Betriebsystem stattfindet, ist das Kernsystem zudem geräteunabhängig.
Anwendungsprogramm
anwendungsorientierte Schicht
sprachabhängige Schicht
Kernsystem
Betriebssystem
andere Betriebsmittel
graphische Betriebsmittel
Abbildung: 1.2.
S.13]
Kernsystems in der Systemhierarchie [DIN 66252 Teil1,
Von der Konzeption war GKS als 2D–System ausgelegt. Im Jahre 1985 wurde eine
3D–Erweiterung als GKS–3D normiert. Bei dieser Definition fehlte allerdings eine
hierarchische Datenstruktur und somit die Voraussetzung zur Verknüpfung von Bildelementen
zu komplexeren 3D-Objekten. Aus diesem Grund ist GKS-3D für die
wichtigste 3D-Anwendung, das Computer Aided Design (CAD), ungeeignet.
2.2.1. Programmierschnittstelle für 3D-Graphiken
Eine geeignetere Anwenderprogramm-Graphiksystem-Schnittstelle für 3D-Graphik
ist das PHIGS-System (Programmer’s Hierarchical Interactive Graphics System),
das im Oktober des Jahres 1986 als ANSI–Norm festgelegt wurde [FO-
LEY90]. Wie schon der Name andeutet, besteht der Hauptunterschied zu GKS in der
konsequenten Beschreibung aller graphischen Objekte mittels hierarchischer Datenstrukturen
als 3D-Modell.
Ein 3D-Objekt wird aus einzelnen geometrischen Primitiven konstruiert, die in einem
gerichteten azyklischen Graphen (DAG) zusammengefaßt werden. Jedes so definierte
Objekt kann in weiteren Definitionen als neues geometrisches Primitiv an-
16

gesehen und verwendet werden. An einem Beispiel aus [FOLEY90] (Abbildung
1.3.) läßt sich der hierarchische Aufbau der Datenstruktur verdeutlichen.
Mit der Datenstruktur des graphischen Objektes Roboter werden gleichzeitig primitivere
graphische Objekte wie Oberkörper, Arm oder Finger definiert.
Roboter
Unterkörper
Oberkörper
Arm
a. 3D–Objekt b. Datenstruktur
Finger
Abbildung: 1.3.
Ein 3D-Objekt als gerichteter azyklischer Graph
Die Erweiterung von PHIGS um Funktionen, die für eine pseudorealistische Darstellung,
d.h. für eine möglichst natürlich anmutende Darstellung, notwendig sind,
heißt PHIGS+. Diese Erweiterungen schließen unter anderem verschiedene Shadingfunktionen,
verschiedene Beleuchtungsmodelle und graphische Grundoperationen
wie Set of Filled Set (SOFAS), Meshes oder Non Uniform Rational B–Splines
(NURBS) ein.
2.2.2. Die Graphics Libary GL
Neben den Standards, welche von offiziellen Gremien verabschiedet werden, gibt
es die sogenannten Industrie- oder de Facto-Standards, die sich über eine breite Akzeptanz
der Benutzer am Markt durchsetzen.
So entwickelte die Firma Silicon Graphics etwa zeitgleich mit der Entwicklung des
PHIGS-Systems die Graphics Libary GL [SILICON91]. Eine Softwareschnittstelle,
die eine Programmierung der leistungsstarken Graphikhardware der Firma ermöglicht.
GL ist als eine weitgehend sprachunabhängige Bibliothek von Unterroutinen realisiert,
die es ermöglichen 2D und 3D Farbgraphiken darzustellen und zu animieren.
Bei der Entwicklung von GL-Graphiken liefert die jeweils verwendete Programmiersprache
die logische Struktur der Anwendung, während die Routinen der Graphics
Libary die Schnittstelle zum Graphiksystem darstellen.
17

2.2.3. IRIS Inventor
Inventor ist eine objektorientierte Erweiterung der Graphics Libary, die aus einer
umfangreichen Klassenbibliothek besteht [INVEN92],[STRAU92]. Die Inventorklassen
ermöglichen eine Definition von 3D-Objekten als sogenannte ’Szenen’ in
Form eines gerichteten azyklischen Graphen ähnlich der hierarchischen Datenstruktur
des PHIGS–Systems.
2.2.3.1. Der Aufbau eines Szenengraphen
Der Graph, der eine dreidimensionale Szene definiert, wird ’Szenengraph’ genannt.
Jeder Knoten des Graphen entspricht einer Informationseinheit, mit der die Szene
beschrieben wird. Es gibt drei verschiedene Arten von Knoten. Formknoten (shapenodes)
beschreiben die Form eines Körpers der Szene. Mit Hilfe der Formknoten
lassen sich Basiskörper definieren, aus denen nach einem ’Baukastenprinzip’ komplexe
Szenen zusammengesetzt werden können.
Dieses ’Zusammensetzten’ entspricht in etwa dem Prinzip des körperorientierten
geometrischen Modellieren durch die Constructive Solid Geometry (CSG) [FO-
LEY92]. In der Constructive Solid Geometry werden die graphischen Objekte in einer
baumartigen Datenstruktur repräsentiert. Die Blätter des Baumes repräsentieren
die graphischen Primitive bzw. Basiskörper, aus denen das gesamte Objekt zusammengesetzt
wird. Transformationen werden durch die inneren Knoten des Baumes
definiert.
Im Szenengraphen des Inventorsystems werden graphische Attribute wie Transformationen
und Materialien durch eine weitere Art von ’Blattknoten’ definiert.
Transformationsknoten beschreiben Rotationen, Translationen und Skalierungen,
welche die Größe, Position und Ausrichtung der einzelnen Szenenobjekte festlegen.
Mit der dritten Knotenart, dem Gruppenknoten, können die objektbeschreibenden
Knoten zu Graphen und Subgraphen zusammengefaßt werden. Die Gruppenknoten
sind also die inneren Knoten des Szenengraphen. Die Gruppenknoten unterscheiden
sich durch die Reihenfolge, in der ihre Kinder beim Vorgang des ’Renderings’ bearbeitet
werden. Das Rendern einer Graphik geschieht durch die in Kapitel 2.1.1. erläuterte
Zeilenrasterung und dem damit verbundenen Beschreiben des Rasterspeichers
(Frame Buffer). Das Rendering einer Datenstruktur ist folglich die
Visualisierung der durch die Struktur definierten Szene.
Abbildung 1.4. zeigt einen Szenengraphen zur Darstellung eines Armes des Roboters
aus Abbildung 1.3.. Ein Eigenschaftsknoten vererbt die durch ihn festgelegten
graphischen Objekteigenschaften in der Struktur des Szenengraphen an die im Graphen
rechts von ihm definierten Teilobjekte der Szene. Folglich müssen die Eigenschaftsknoten
im Szenengraphen immer links der Objekte stehen, die sie beeinflussen
sollen. Der in Abbildung 1.4. dargestellte Knoten cube, welcher einen Quader
definiert, erbt die durch die Knoten transformation und material definierten graphischen
Eigenschaften und erhält so seine Oberflächenstruktur, seine Größe und seine
Position im Raum.
18

Arm–Gruppe
transformation material cube
Der Roboterarm aus Abbildung 1.3. als Inventor Szenen-
Abbildung: 1.4.
graph
Die Festlegung der graphischen Attribute als Objekte und ihre Eingliederung in die
Hierarchie des Szenengraphen hat den Vorteil, daß Eigenschaften nicht für jedes
graphische Objekt neu definiert werden müssen. Ein Eigenschaftsknoten beeinflußt
alle graphischen Objekte, die rechts von ihm im Szenegraphen eingebunden sind.
Das Material des gesamten Roboters muß in unserem Beispiel also nur durch einen
Materialknoten, der sich ganz links oben im Graphen befindet, festgelegt werden.
Abbildung 1.5. zeigt einen Szenengraphen, mit dem der gesamte Roboter repräsentiert
wird. Links neben jedem Formknoten und jedem Gruppenknoten liegen jeweils
die Transformationsknoten, welche die Transformationen der Basiskörper und der
durch die Gruppenknoten definierten graphischen Teilobjekte beinhalten. Der Materialknoten
direkt unter dem Wurzelknoten beeinflußt alle Formknoten des Szenengraphen
und legt somit daß Material der gesamten Szene fest.
19

Roboter
material
Oberkörper
Kopf
Bein
trans.
cube
Arme
trans.
cube
trans.
cube
trans.
linker Arm
trans.
rechter Arm
trans.
cube
trans.
cube
Abbildung: 1.5. Szenengraph des Roboters aus Abbildung 1.3.
2.2.3.2. Definition von graphischen Teilobjekten durch Pfade
Der Vorteil einer hierarchischen Datenstruktur zur Repräsentation einer Szene ist die
Verknüpfung von Bildelementen zu komplexen 3D-Objekten und Szenen. Es können
dadurch die Teilobjekte einer Szene erkannt, ausgewählt und verändert werden.
Dies ist insbesondere zur Entwicklung interaktiver Graphiken notwendig, um Interaktionen
auf Teilen einer Szene durchführen zu können.
Bei einer Szenendefinition mittels eines Szenengraphen tritt das Problem auf, daß
Teilobjekte mehrfach im Graphen auftreten können. So werden im Beispiel des
’Roboterszenengraphen’ der linke und der rechte Arm des Roboters durch die gleiche
Gruppe von ’Blattknoten’ definiert. Ein bestimmtes Teilobjekt der Szene kann
also nur durch eine Knotenliste, die alle Knoten von der Wurzel des Szenengraphen
bis zur Wurzel des Teilobjekts enthält, spezifiziert werden.
Eine solche Liste von Knoten heißt im Inventor-System Pfad. Wenn der Benutzer
einer interaktiven Graphik ein Teilobjekt der Szene auswählt, so wählt er den Pfad
im Szenengraphen aus, der das Teilobjekt spezifiziert.
20

Abbildung 1.6. zeigt den Pfad im ’Roboterszenengraphen’, der den Finger des linken
Arms des Roboters spezifiziert.
Roboter
Oberkörper
Kopf
Bein
Arme
linker Arm
rechter Arm
Oberarm
Finger
Abbildung: 1.6.
Beispiel eines Pfades in einem Szenengraphen
2.2.3.3. Operationen auf dem Szenengraphen
Auf den gesamten Szenengraphen sowie auf Teile deselben können Operationen angewendet
werden. Diese als sogenannte ’Actions’ definierten Operationen werden
entweder an die Wurzel des Szenengraphen oder an einen Pfad im Graphen angehängt.
Bei der Aktivierung einer solchen Aktion wird der Szenengraph von links
oben nach rechts unten traversiert und in jedem Knoten wird eine der Aktion zugeordnete
Reaktion hervorgerufen. So gibt es zum Beispiel eine Inventor Aktion die
das Rendern, d.h. die Visualisierung des Szenegraphen bewirkt.
2.3. Stand der Eingabegerätetechnik
Mit der Entwicklung neuer Graphiksysteme entsteht auch immer eine Nachfrage
nach neuartigen Eingabegeräten, die den Möglichkeiten der Graphik und dem Inter-
21

aktionsbedürfnis des Benutzers besser gerecht werden als Geräte, welche für eine
alphanummerische Datenverarbeitung entwickelt wurden. So hat sich die Maus als
Eingabegerät für interaktive zweidimensionale Graphik, insbesondere durch die
Mitte der 80er Jahre entwickelten fensterbasierten zweidimensionalen Benutzeroberflächen,
durchgesetzt.
2.3.1. Tastatureingabegeräte
Bei Graphikanwendungen besteht eine Benutzerinteraktion oft aus einer kontinuierlichen
Bewegung von graphischen Objekten der Darstellung. So muß zum Beispiel
bei einer fensterbasierten Benutzeroberfläche der Mauszeiger in der Bildschirmebene
bewegt werden.
Zur Steuerung einer graphischen Anwendung mit einer Tastatur muß jede mögliche
Bewegungsrichtung der Objekte durch eine bestimmte Taste ausgelöst werden. Eine
solche Steuerung ist nicht intuitiv verständlich, da es für den Benutzer nicht ersichtlich
ist welche Taste welche Bewegung in der Darstellung auslöst.
Ein weiteres Problem der Bewegungssteuerung durch Tastendruck oder Halten einer
Taste während der Bewegung ist, daß der Benutzer nicht die Geschwindigkeit
der Bewegung durch die Geschwindigkeit seiner Eingabeaktion beeinflußen kann.
Je mehr verschiedene Interaktionsmöglichkeiten dem Benutzer zur Anwendungssteuerung
zur Verfügung gestellt werden, desto mehr Tasten müssen mit Bewegungsrichtungen
der graphischen Objekte belegt werden. Bei komplizierteren Systemen
ist es daher nur einem geübten Benutzer möglich, die Graphikanwendung
über eine Tastatur zu steuern.
2.3.2. Graphische Eingabegeräte
In zweidimensionalen Graphikanwendungen muß der Benutzer folgende Objektbewegungen
und Aktionen ausführen können:
Translation in der Darstellungsebene, d.h. Veränderung der
Position in der Ebene.
Rotation des Objektes, d.h. Veränderung der Objektausrichtung.
Auswahl eines Objektes der Darstellung.
Um eine Translation in der Ebene durchzuführen muß das Eingabegerät über zwei
Freiheitsgrade verfügen. Ein zusätzlicher Freiheitsgrad wird zur Manipulation der
Objektorientierung in der Ebene benötigt. Zur Objektauswahl ist eine Taste am Eingabegerät
ausreichend.
22

Als Eingabegerät für die Interaktion mit zweidimensionaler Graphik, hat sich neben
dem Lichtgriffel und dem graphischen Tablett besonders die Maus durchgesetzt.
Diese ’2D-Eingabegeräte’ verfügen jeweils über zwei Freiheitsgrade, und eine
Möglichkeit zur Objektauswahl. Aufgrund des fehlenden dritten Freiheitsgrades
wird die Objektrotation simuliert. Bei der Maus kann dies zum Beispiel durch drükken
einer Maustaste während einer Seitwärtsbewegung realisiert werden.
y
y
x
x
z
Abbildung: 1.7.
Freiheitsgrade in zwei- und dreidimensionaler Graphik
Zur Manipulation dreidimensionaler Szenen lassen sich die folgenden Bewegungen
und Aktionen definieren [FELGER92]:
Translation eines Objekts, d.h. Veränderung der Objektposition
im Raum.
Rotation eines Objekts der Szene, d.h. Veränderung der
Objektausrichtung im Raum.
Auswahl von Szenenobjekten.
Im Vergleich zur Interaktion mit zweidimensionalen Graphiken muß ein Eingabegerät
für eine dreidimensionale Graphik über sechs Freiheitsgrade verfügen. Drei für
die Translationen in Richtung der drei Achsen welche den Darstellungsraum aufspannen
und drei zur Durchführung der Rotationen um die drei Achsen.
2.3.2.1. Manipulation dreidimensionaler Graphik mit der Maus
Um mit Eingabegeräten mit weniger Freiheitsgraden dreidimensionale Graphiken
manipulieren zu können, müssen mehrere Bewegungen auf eine Eingabebewegung
abgebildet werden.
23

Eine solche Mehrfachbelegung von Freiheitsgraden des Eingabegerätes läßt sich
wiederum für die Maus definieren:
Gedrückt halten der linken Maustaste während der Mausbewegung
verursacht eine Translation in der xy-Ebene und
gleichzeitiges gedrückt halten der linken und der mittleren
Maustaste während der Mausbewegung verursacht eine
Translation in der xz-Ebene.
y
x
z
y
x
z
Gedrückt halten der mittleren Maustaste während der
Mausbewegung verursacht die Rotation des graphischen
Objekts um eine virtuelle Kugel.
y
x
z
Die unbenutzte rechte Maustaste bleibt zum Auswählen
graphischer Objekte der Szene.
2.3.2.2. Der Spaceball, Eingabegerät mit sechs Freiheitsgraden
Der Spaceball ist ein stationäres Eingabegerät in Form einer Kugel [FOLEY90],
[SPACE91]. Der Benutzer kann Kraft auf diese Kugel in Richtung der Translationen
und Rotationen ausüben. Die ausgeübte Kraft wird auf die Veränderung von Position
24

und Orientierung der Objekte der Szene abgebildet (s. Abbildung 1.8.). Der Spaceball
ist folglich eine Eingabegerät mit sechs Freiheitsgraden.
1
y
4
4
2
6 3 5
1
6
2 2
3
2
5
x
3
3
1
1
z
Abbildung: 1.8.
Abbildung der Kräfte auf Bewegungen
Zur Objektauswahl steht dem Benutzer eine Taste auf der Kugeloberfläche zur Verfügung,
die er mit der gleichen Hand bedienen kann, mit der er die Objektbewegung
steuert.
Ein Nachteil, welcher das intuitive Verständnis des Benutzers für die Interaktion erschweren
kann, ist, daß nicht eine Bewegung der Hand sondern das Ausüben einer
Kraft Bewegungen der graphischen Objekte verursacht.
2.3.2.3. Der Datenhandschuh
Mit einem Datenhandschuh als Eingabegerät für eine Graphikanwendung, kann der
Benutzer durch Bewegung seiner Hand mit der Anwendung interagieren.
Die Realisierung eines solchen Datenhandschuhs ist der ’DataGlove’ von VPL Research.
Er kann die Handposition und -orientierung und die Bewegung der einzelnen
Finger als Eingabe an die Anwendung liefern.
Der DataGlove ist ein Handschuh auf dessen Rückenfläche fünf lichtempfindliche
Sensoren aufgenäht sind, die dazu dienen den Grad der Fingerkrümmung aufzunehmen.
Jeder Sensor besteht aus einem kurzen Fieberglaskabel an dessen beiden Enden
eine Leuchtdiode und ein Photowiderstand angebracht sind. Die Intensität des
Lichtes der Leuchtdiode welches auf den Photowiderstand trifft, ist proportional zur
Krümmung des betreffenden Fingers.
Position und Orientierung des Handschuhs werden mit einem auf dem Handschuhrücken
befestigtem 6D-Sensors, dem ’3Space Isotrack’ von Polhemus aufgenommen.
25

Der Datenhandschuh ist wie der Spaceball ein graphisches Eingabegerät mit sechs
Freiheitsgraden. Er vermittelt dem Benutzer ein intuitiveres Verständnis für die Interaktion
mit dreidimensionalen Szenen, da die Bewegung der Szenenobjekte durch
eine gleichartige Bewegung des Eingabegerätes gesteuert werden kann.
Desweiteren können mit Hilfe der Werte des Krümmungsgrades der einzelnen Finger
Handgesten und -posen definiert werden, mit denen der Benutzer bestimmte Aktionen
ausführen und Reaktionen der Anwendung hervorrufen kann [BORD93]. So
kann zum Beispiel das Auswählen eines graphischen Objektes durch das ’Greifen’
nach dem Objekt erfolgen.
26

3. Information Retrieval
Ein Information-Retrieval-System ist ein Computer Programm, mit dem für eine
Problemstellung relevante Information aus einer großen Informationsmenge extrahiert
werden kann.
Im folgenden nennen wir die ’große Informationsmenge’ Datenbank. Die Information
innerhalb der Datenbank besteht aus Dokumenten. Wenn wir also von Wiedergewinnung
relevanter Information sprechen, wollen wir diejenige Menge von Dokumenten
aus der Datenbank extrahieren, die bezüglich unseres Interesses relevant
ist. Unser Interesse formulieren wir in einer Anfrage, auf die das Retrieval-System
durch Präsentation der relevanten Dokumente reagiert.
Trivialerweise würde ein Retrieval-System, welches auf jede Anfrage immer alle
Dokumente als Ergebnismenge präsentiert, immer auch das Benutzerinteresse erfüllen,
solange überhaupt relevante Dokumente in der Datenbank existieren. Zur Effektivität
eines Information-Retrieval-Systems gehört also nicht nur das sichere Finden
der gesuchten Information, sondern auch das sichere Ausblenden der nicht
gesuchten Information. Als Maß für die Effektivität werden darum precision und recall
angegeben[ENDN89].
precision
recall
gefundene und relevante Dokumente
gefundene Dokumente
gefundene und relevante Dokumente
relevante Dokumente
Beide Werte sind wegen ihrer Relevanzabschätzungen schlecht operationalisierbar.
Sie vedeutlichen aber den Konflikt zwischen Ergebnismengen mit vielen nicht relevanten
Dokumenten und Ergebnismengen, in denen viele relevante Dokumente fehlen.
3.1. Aufbau von Information–Retrieval–Systemen
Ein Information-Retrieval-System läßt sich in drei funktional getrennte Komponenten
zerlegen. Eine Schnittstelle erlaubt die Steuerung des Systems. Die Retrieval–
Maschine dient der Wiedergewinnung der gesuchten Information und die Dateiorganisation
ist für die Speicherung der Datenbasis zuständig. Abbildung 2.1. zeigt die
27

Abhängigkeiten der Komponenten und den schematischen Ablauf eines iterativen
Retrievalprozesses.
Suchanfrage
einlesen
Transitions
datei
Suchanfrage
absetzen
Suchwort
datei
Retrieval–
Maschine
Ergebnismenge
präsentieren
Text
datei
Ja
neue
Anfrage
stellen?
Nein
Ende
Schnittstelle Retrieval-Maschine Dateiorganisation
Abbildung: 2.1.
Iterativer Retrievalprozeß
28

3.1.1. Retrieval-Maschine
Die Retrieval–Maschine beinhaltet den Informationswiedergewinnungsprozeß. Eine
Anfrage wird ausgewertet, indem, je nach zugrunde liegendem Modell, die Menge
der Dokumente bestimmt wird, die die Anfrage erfüllen. Die verschiedenen Auswertungsstrategien
bieten sich für eine Klassifizierung von
Information-Retrieval-Systemen an. In [BELKIN92] wird vorgeschlagen, drei Modelle
zu unterscheiden.
3.1.1.1. Boolesches Retrieval
Das boolesche Retrieval-Modell basiert auf exakter Erfüllung einer Anfrage durch
ein Dokument. Eine Anfrage besteht aus Suchwörtern oder Sätzen, die durch boolesche
Operatoren verknüpft werden. Ein Dokument erfüllt die Anfrage, wenn es die
Suchwörter oder Sätze in der durch die booleschen Operatoren geforderten Konstellation
enthält. Gehen wir zum Beispiel von den booleschen Operatoren AND, OR
und NOT aus, und nehmen an, daß A, B, C und D Suchwörter sind. Die Anfrage
AND(A OR(B C) NOT(D)) wird von allen Dokumenten erfüllt, die A enthalten und
B oder C enthalten und D nicht enthalten.
Eine Unterscheidung der Dokumente in der Ergebnismenge findet nicht statt. Insbesondere
wird keinerlei Relevanz der Dokumente in oder außerhalb der Ergebnismenge
berücksichtigt.
3.1.1.2. Best-Match Retrieval
Im Retrieval-Modell des Best-Match wird die Forderung nach exakter Erfüllung der
Anfrage aufgegeben und dafür eine Sortierung der Dokumente nach dem Grad ihrer
Erfüllung der Anfrage eingeführt. Durch die Beispielanfrage AND(A OR(B C)
NOT(D)) könnte durchaus ein Dokument gefunden werden, in dem das Wort D, trotz
der Forderung NOT(D), vorkommt. Dies ist sinnvoll, wenn D als wenig relevant eingestuft
und der Rest der Anfrage mit hoher Übereinstimmung erfüllt wird.
Zentrale Frage dieses Modells ist die Bewertung der Relevanz, die ein Suchwort für
ein Dokument hat. Grundlage dieses Retrieval-Modells ist die Idee, daß ein Dokument
als Vektor in einem Inhaltsraum aufgefaßt werden kann. Im Kapitel 3.5. gehen
wir auf vektorbasierte Systeme genauer ein.
3.1.1.3. Probabilistisches Retrieval
Bezüglich der Erfassung des Inhaltes eines Dokumentes und der Erfassung des Benutzerinteresses
durch eine Anfrage besteht Unsicherheit. Dieses Modell versucht
dem Rechnung zu tragen, indem mit Mitteln der Wahrscheinlichkeitsrechnung abgeschätzt
wird, wie gut ein Dokument das Benutzerinteresse erfüllt. Statistische Verteilungen
und Vorkommenshäufigkeiten von Begriffen spielen dabei eine wichtige
29

Rolle. INQUERY ist ein probabilistisches Retrieval-System und wird in Kapitel 3.6.
ausführlich vorgestellt.
3.2. Dateiorganisation eines Information-Retrieval-
Systems
Basis vieler Information–Retrieval–Systeme sind drei Dateitypen [ENDN89]. In einer
Textdatei sind alle Informationen als Text abgelegt. In einer Suchwortdatei sind
alle Begriffe gespeichert, die als Suchwort dienen können und in einer Transitionsdatei
werden schließlich Verweise zwischen Suchwort und zugehörigem Text abgelegt.
Diese drei Dateien bilden die Datenbasis des Systems. Abbildung 2.2. auf Seite
31 veranschaulicht den schematischen Aufbau der Datenbasis. Beispielhaft sind in
der Textdatei die zwei Einträge D1 und D2 wiedergegeben. Zwischen dem Suchwort
’energy’ und dem Dokument D1 besteht ein Verweis. Der Verweis ist in der Transitionsdatei
enthalten und ist durch t1 gekennzeichnet. Ein zweiter Verweis besteht
zwischen ’solar’ und D2. Dieses Beispiel ist der CORDIS-Datenbank über EG Projekte
entnommen. Tatsächlich gehen von den Suchwörtern ’energy’ und ’solar’ eine
Vielzahl von weiteren Verweisen aus. Auch die beiden Beispieldokumente werden
von einer Vielzahl von Verweisen getroffen.
3.3. Schnittstellen
Als Grundtypen für Schnittstellen lassen sich interaktive Benutzerschnittstellen und
Programmierschnittstellen unterscheiden. Das im Kapitel 3.4. vorgestellte PUBLI-
CAT-System verfügt über eine interaktive Benutzerschnittstelle. Das im Kapitel
3.6.4.1. beschriebene Application Programmers Interface von INQUERY ist ein
Beispiel für eine Programmierschnittstelle.
Strategien zur Erhöhung der Benutzerfreundlichkeit setzen oft bei der Schnittstelle
an. Sie zielen darauf ab, dem Benutzer möglichst komfortable Unterstützung bei der
Erstellung seiner Suchanfrage zu leisten. Als Beispiele seien hier die Benutzerführung
durch graphische Oberflächen und wissensbasierte Systeme genannt, die phonetische
Suche unterstützen, Synonyme erkennen oder eine quasi natürlichsprachlich
formulierte Suchanfrage akzeptieren.
30

Textdatei
31
Abbildung: 2.2. Dateiorganisation eines Information-Retrieval-Systems
Suchwort
Datei
aalbog
abat
abb
abbrev
endurance
enea
energy
energetic
soil
sol
solar
solderability
solenoid
ZrNiAl
ZrO(2)
zylene
Transitions
Datei
t1
t2
D1
D2
TENTH EC PHOTOVOLTAIC SOLAR ENERGY CONFERENCE
Around 350 contributions from 53 countries were presented at the proceedings of
the 10th European Photovoltaic Solar Energy Conference. Session topics included:
– high efficiency cells and novel devices
– crystalline silicon materials and devices
– amorphous silicon and related materials and alloys
– photovoltaic (PV) systems technology – compound semiconductor solar cells
– hybrid and utility photovoltaics – stand–alone PV systems
– PVs in developing countries – organisation and training needs
– national programms and
– international aid.
The Panel discussion dealt with the topic of mass production of PV electricity.
THERMAL COMFORT IN BUILDINGS WITH PASSIVE SOLAR FEATURES
Field studies in domestic and non–domestic buildings in France, Germany and Grat
Britain have been performed in order to assess thermal comfort in buildings with
passivs solar features. Air and global temperatures, air velocity and relative humidity
were measured, while respondents completed a questionnaire which gave details of
activity levels and clothing worn. They also described their thermal sensations on a
9–point rating scale, as well as their environmental priorities. Results are published for
each building type. One of the general conclusions is that there do not appear to be
significant differences between buildings with passive solar features ans those without,
in terms of the experience of their occupants. The general satisfaction with passive
solar houses was, however, very high.

3.4. PUBLICAT
Am Beispiel von PUBLICAT soll in diesem Kapitel gezeigt werden, wie die Recherche
mit einem konventionellen Retrieval-System abläuft. Es wurde bewußt auf
die Beschreibung der umfangreichen, zusätzlichen Funktionalität des Systems verzichtet,
um nicht vom eigentlichen Retrievalprozeß abzulenken. Im Vordergrund
des folgenden Textes steht aus diesem Grund die Benutzerschnittstelle und der Sitzungsverlauf.
PUBLICAT enthält als Datenbank den Zentralkatalog der GMD-Bibliotheken also
eine bibliographische Datenbank. Die Dokumente der Datenbank sind kurze und
stark strukturierte Texte. Der Umfang der Datenbank beträgt etwa 100000 Einträge.
Die Retrieval-Engine des Systems folgt dem booleschen Modell. Die Anfrage des
Benutzers führt zu einer Ergebnisliste, in der alle Dokumente aufgeführt sind, die
die Anfrage im booleschen Sinn mit TRUE erfüllen. Wir werden sehen, daß boolesches
Retrieval anfällig für den unbeabsichtigten Ausschluß von relevanten Dokumenten
ist und das PUBLICAT Möglichkeiten bietet, dieser Gefahr zu begegnen.
Die Benutzerschnittstelle ist als Fenstersystem realisiert. Zur Benutzerführung stehen
Eingabefelder, Buttons, Menüs zur Verfügung. Die Formulierung der Suchanfragen
wird komfortabel unterstützt.
3.4.1. Recherchefenster
Die Recherche im Bibliothekskatalog beginnt mit dem Recherchefenster. In den
Maskenfeldern können Suchbegriffe eingetragen werden. Die Maskenfelder korrespondieren
mit den Feldern der Datenbank. Die Angabe eines Suchbegriffs im Feld
’Titel’ hat eine Suche des Begriffs in den Titelfeldern der Bibliotheksdatenbank zur
Folge.
In den Maskenfeldern können Suchbegriffe eingetragen werden. Nimmt man Eintragungen
in mehreren Feldern vor oder gibt mehrere Wörter in einem Feld ein, so
werden diese in der Suchanfrage mit AND verknüpft. Die Eingabe der Suchbegriffe
’virtual’ und ’reality’ im Titelfeld führt zu einer Suche nach allen Dokumenten, in
deren Titel sowohl das Wort ’virtual’ als auch das Wort ’reality’ vorkommt. PUBLI-
CAT findet 18 Einträge. Wünscht man eine oder-Verknüpfung der Begriffe, so kann
man den OR-Operator explizit angeben. Die Suche nach ’virtual OR reality’ findet
149 Einträge.
Mit einem ’?’ kann man Suchbegriffe trunkieren. Der Suchbegriff ’retrieval?’ paßt
in seiner trunkierten Form auf die Wörter ’retrieval’, ’retrievalsoftware’, ’retrievalsystem’
usw. Das Trunkieren von Suchbegriffen ist ein Mittel, um die oft unerwünschte
Forderung nach exakter Übereinstimmung von booleschen Retrieval-Maschinen
aufzuweichen. Eine Suche mit der Eintragung ’Croft’ im Personenfeld geht
32

leer aus, die Suche nach ’Croft, Bruce’ findet zwei Einträge, die Suche nach ’Croft,
?’ liefert sieben Treffer. Nach kurzer Sichtung stellt sich heraus, daß alle relevant
sind.
Spezifiziert man im Feld ’Ersch. Jahr’ das Erscheinungsjahr einer Veröffentlichung,
kann das boolesche Retrieval schnell zu lästigen Einschränkungen führen.
Will man seine Suche zum Beispiel auf Veröffentlichungen der letzten zehn Jahre
beschränken, müßte der Eintrag lauten ’1993 OR 1992 OR 1991 OR 1990 OR ... OR
1984’. Zur komfortableren Spezifikation solcher Anfragen ist in diesem Feld die
Verwendung der Vergleichsoperatoren ’>’, ’=’, und ’= 1984’ spezifiziert werden.
In einem Ausgabefeld werden die generierten Anfragen und ihre Trefferzahl aufgelistet.
Durch Mausselektion läßt sich eine frühere Anfrage wieder aktivieren. Mehrere
frühere Anfragen lassen sich durch oder-Verknüpfung oder durch und-Verknüpfung
kombinieren. Der Benutzer selektiert sie dazu mit der Maus und wählt die
Verknüpfung durch anklicken der Buttons ’Einsch. (AND)’ oder ’Erw. (OR)’ .
Abbildung 2.3. zeigt das Recherchefenster. Die erwähnten Eingabebeispiele stehen
noch im Suchanfrageausgabefeld.
Abbildung: 2.3.
Recherchefenster
3.4.2. Ergebnisfenster
Nachdem der Benutzer im Recherchefenster alle gewünschten Eingaben vorgenommen
hat, betätigt er den ’Suchen’ Button. Das System generiert darauf eine Anfrage
33

in einem speziellen Syntax und übergibt ihn der Retrieval-Maschine. Nach der Evaluierung
meldet sich die Benutzerschnittstelle mit dem Ergebnisfenster zurück.
Des Ergebnisfenster gibt Auskunft über die Anzahl der gefundenen Einträge. In einer
blätterbaren Kurztitelanzeige wird die Ergebnisliste präsentiert. Jedes Element
der Liste wird in einer Zeile dargestellt, die Titel, Autor und Erscheinungsjahr des
gefundenen Dokuments wiedergibt. Die Kurztitelanzeige umfaßt acht Zeilen. Ist die
Trefferanzahl höher, kann die Liste geblättert werden.
In Folge der booleschen Retrievalmaschine läßt die Stellung eines Dokuments in der
Liste keinerlei Aufschluß über dessen Relevanz zu. Alle Einträge der Liste erfüllen
exakt die Anfrage und sind völlig gleichberechtigt.
Als Beispiel ist in Abbildung 2.4. das Ergebnisfenster einer Anfrage abgebildet. Die
Anfrage spezifizierte als Erscheinungsjahr ’>= 1993’ und als Titel ’retrieval?’. Die
Ergebnisliste enthält also alle Dokumente, die im Jahr 1993 erschienen sind und in
deren Titel ein Wort vorkommt, welches mit der Buchstabenfolge ’retrieval’ beginnt.
PUBLICAT findet 14 Treffer.
Abbildung: 2.4.
Ergebnisfenster
3.4.3. Vollanzeigefenster
Die Information aus der Kurztitelanzeige ermöglicht dem Benutzer einen groben
Überblick über das Ergebnis der Suche. Mit der Vollanzeige können die Details eines
gefundenen Eintrags angezeigt werden. Der Benutzer selektiert dazu eine Zeile
der Ergebnisliste in der Kurztitelanzeige und betätigt den ’Vollanzeige’-Button.
34

Das Vollanzeigefenster ist dem Ergebnisfenster sehr ähnlich. Es enthält ebenfalls
das achtzeilige Ausgabefenster, das aber nun ganz den bibliogaphischen Daten und
Statusinformationen eines Buches zur Verfügung steht. Benötigen diese mehr als
acht Zeilen, so kann auch hier geblättert werden. Wenn ein Buch verliehen ist, befindet
sich ein entsprechender Eintrag in der Anzeige.
Abbildung: 2.5.
Vollanzeigefenster
35

3.5. Vektorbasierte IR Systeme
Vektorbasierte Modelle sind im Bereich des Best-Match Retrieval weit verbreitet.
Grundlage dieses Modells ist die Idee, daß ein Dokument als Vektor in einem Inhaltsraum
aufgefaßt werden kann. Die inhaltliche Verwandschaft von verschiedenen
Dokumenten untereinander oder bezüglich einer Anfrage kann durch den Abstand
von Vektoren zum Ausdruck gebracht werden.
Zentrale Eigenschaft dieses Modells ist die Berücksichtigung der Relevanz eines
Begriffes bezüglich eines Dokuments und der Relevanz eines Suchbegriffs bezüglich
der Anfrage.
3.5.1. Inhaltsraum
Der Inhaltsraum einer Datenbasis ist der Vektorraum der Dokumentvektoren. Er
umschließt die Information, die in der Dokumentenmenge enthalten ist. Diese Information
besteht aus der Gesamtheit der Themen, die in den Dokumenten behandelt
werden. Die Themen werden durch die Begriffe definiert, mit welchen sie beschrieben
sind.
Der Inhalt content eines Dokumentes d läßt sich dann folgendermaßen als Vektor D
von inhaltsspezifizierenden Begriffen w 1 bis w m beschreiben [s. HEMMJE92]:
content(d) (w 1 , w 2 , w 3 , ... ,w m ) D
Ein ’inhaltsspezifizierender Begriff’ muß hierbei keinesweg ein einzelnes Wort
sein. Es kann sich dabei genausogut um eine Klasse von Worten, einen bestimmten
Worttyp (zB. ein Firmenname) oder, entfernt man sich von reinen Textdaten, auch
beliebige andere Information wie zum Beispiel Video– oder Audiomaterial handeln.
Der Inhalt content eines Begriffes w läßt sich dann folgendermaßen als Vektor W
beschreiben:
content(w) (text(w), video(w), audio(w), typ(w), ...) W
Für eine genaue Beschreibung des Dokumenteninhalts ist es jedoch nicht ausreichend,
nur die in ihm enthaltenen Begriffe aufzulisten. Von Bedeutung ist auch die
Relvanz, die ein Begriff für den Inhalt eines Dokuments hat. Zum Informationsinhalt
eines Begriffes kommt aus diesem Grund noch ein Maß für die Relevanz bezüglich
jedes Dokuments in der Dokumentenmenge hinzu. Die Funktion g(w,d) gibt die
Relevanz des Wortes w im Dokument d an.
36

w (content(w), g(w, d 1 ), g(w, d 2 ), ... , g(w, d i ))
Der Inhalt eines Dokuments d i setzt sich nur aus seinen relevanten Begriffen w 1 bis
w m zusammen. Die Gewichtungen der relevanten Begriffe bezüglich der anderen
Dokumente d k (ki) ist für d i nicht von Bedeutung. Wir extrahieren die benötigte Information
durch die Definition
w d (content(w), g(w, d))
und können so eine umfassende Definition des Dokumentinhalts angeben. Ein Dokument
besteht nun aus einem Vektor gewichteter ’inhaltsspezifizierender Begriffe’,
denen inhaltliche Information beliebiger Art zugeordnet sein kann.
content(d) (w 1d , w 2d , w 3d , ... , w md )
((content(w 1d ), g(w 1 , d)), ... , (content(w md ), g(w m , d)))
D
Retrieval-Systeme, die sich auf Textdatenbanken stützen und die Wiedergewinnung
von Texten durch textuelle Suchbegriffe erlauben, nutzen einen Spezialfall des ’inhaltsspezifizierenden
Begriffs’. Der Inhalt eines Begriffs besteht in diesem Fall nur
aus textueller Information. Wir gehen im folgenden ebenfalls von diesem vereinfachten
Begriff aus, verwenden also Begriff und Wort sowie Suchbegriff und Suchwort
synonym. Die Relevanz eines Wortes bezüglich eines Dokuments soll weiterhin
berücksichtigt werden. Der Inhalt eines Textdokuments ergibt sich aus Wörtern
und deren Relevanz.
content(d text ) (w text
1d , wtext 2d , wtext 3d
, ... , wtext
md )
((text(w 1d ), g(w 1 , d)), ... , (text(w md ), g(w m , d)))
D
3.5.1.1. Interessenraum
Analog zu den Begriffen Inhaltsraum und Dokumenteninhalt läßt sich der Interessenraum
und das Benutzerinteresse definieren. Der Interessenraum ist die Menge aller
möglichen Informationsbedürfnisse der Benutzer, die in der Datenbank nach Informationen
suchen. Das Benutzerinteresse interest eines Benutzers u ist ein Vektor
A von inhaltsspezifizierenden Begriffen i 1 bis i n [HEMMJE92]:
37

interest(u) (i 1 , i 2 , i 3 , ... ,i n ) A
Die ’inhaltsspezifizierenden Begriffe’ des Anfragenetzes haben grundsätzlich die
gleichen Eigenschaften, wie die des Inhaltsnetzes. Auch hier sind Suchwörter, also
textuelle Begriffe ein Spezialfall von Begriffen mit beliebiger Informationsdarstellung.
content(i) (text(i), video(i), audio(i), typ(i), ...) A
Wie beim Inhaltsnetz gehen wir auch beim Anfragenetz von einem einfachen ’inhaltsspezifizierenden
Begriff’ aus, der aus einem einzelnen Wort besteht, welchem
analog zur Relevanz eines Begriffs in einem Dokument eine Relevanz des Suchbegriffs
bezüglich der Anfrage zugeordnet ist.
Durch diese Bewertung ist es dem Benutzer möglich, die Treffsicherheit der Anfrage
zu erhöhen, indem er von der Möglichkeit Gebrauch macht, die Relevanz der von
ihm gewählten Suchbegriffe zu spezifizieren.
i (content(i), d(i))
Die Funktion d(i) ordnet dem interessenspezifizierenden Begriff i eine Relevanz zu.
Im Kapitel 4.2.3. ist beschrieben, in welcher Weise es dem Benutzer ermöglicht werden
kann, Relevanzwerte zu spezifizieren. Der Interessenvektor läßt sich durch Hinzunahme
der Relevanz folgendermaßen präzisieren:
interest(u) (i 1 , i 2 , i 3 , ... ,i n )
((content(i 1 ), d(i 1 )), ... , (content(i n ), d(i n )))
A
Die Definitionen des Dokumentinhalts und des Benutzerinteresses sind nun typkompatibel.
Sowohl die Dokumente des Inhaltsraumes als auch die Benutzerinteressen
des Interessenraums bestehen aus Vektoren aus Begriffs–Gewicht–Paaren. Gewährleistet
man eine einheitliche Skalierung der Gewichtungswerte, lassen sich
Inhaltsvektoren und Interessenvektoren direkt vergleichen. Ein Dokument erfüllt
das Benutzerinteresse, wenn beide Vektoren identisch sind. Der Abstand zwischen
dem Benutzerinteresse und einem Dokument ist der Differenzvektor zwischen beiden
Vektoren. Die Länge des Differenzvektors gibt Auskunft über das Maß, mit dem
38

ein Dokument vom Benutzerinteresse abweicht. Die Abweichung identischer Vektoren
ist Null.
Bei den geläufigen Vektoren der linearen Algebra ist die i–te Komponente des Vektors
dessen Richtungsanteil in der i–ten Dimension. Vektoren, auf die man Operationen
wie Subtraktion anwendet, müssen in ihrer Dimensionalität übereinstimmen.
Inhalts und Interessenvektor weisen diese Übereinstimmung bestenfalls in wenigen
Ausnahmefällen auf. Wir können eine Übereinstimmung der Dimensionalität aber
einfach erreichen, indem wir die Begriffe in den Vektoren so umsortieren, daß gleiche
Begriffe gleiche Indizes bekommen. Begriffe, die in einem Vektor vorkommen,
im anderen aber fehlen, werden durch Einfügen des fehlenden Begriffs mit Gewichtung
Null ergänzt. Weder das Benutzerinteresse noch der Dokumentinhalt wird dadurch
verändert. Wir erhalten einen Interessenvektor A und einen Inhaltsvektor W
mit folgenden Eigenschaften:
i k A w l W : k l content(i k ) content(w l )
Der Differenzvektor zwischen Interessenvektor und Inhaltsvektor läßt sich berechnen,
indem die Gewichtswerte der korrespondierenden Dimensionen subtrahiert
werden.
A D interest(u) content(d)
(i 1 , i 2 , i 3 , ... , i n ) (w 1 , w 2 , w 3 , ... , w m )
((content(i 1 ), d(i 1 )), ... , (content(i n ), d(i n )))
((content(w 1d ), g(w 1 , d)), ... , (content(w md ), g(w m , d)))
((content(i 1 ), d(i 1 )), ... , (content(i n ), d(i n )))
((content(i 1 ), g(w 1 , d)), ... , (content(i n ), g(w m , d)))
((content(i 1 ), d(i 1 ) g(w 1 , d)), ... , (content(i n ), d(i n ) g(w m , d)))
Die Abweichung von Benutzerinteresse zu Dokumentinhalt ergibt sich aus der Länge
des Differenzvektors |A–D|.
39

3.6. INQUERY
Dieses Kapitel beschreibt das Information-Retrieval-System INQUERY, auf welchem
die in dieser Arbeit behandelte, visuelle Benutzerschnittstelle aufsetzt. IN-
QUERY folgt dem probabilistischen Retrieval-Modell und ist durch seine effizienten
Subsysteme sehr gut für den Umgang mit umfangreichen Volltextdatenbanken
geeignet.
INQUERY wurde am Information-Retrieval-Labor der Universität von Massachusetts
entwickelt. Das System ist speziell auf die Aufgabenstellung zugeschnitten, mit
Volltexten großer Anzahl und großer Länge umzugehen. Konkrete Tests des Systems
wurden dabei mit einer Datenbasis mit einem Volumen von ca. 1 Gigabyte
durchgeführt. Die Anzahl der Dokumente in der Datenbasis betrug etwa 400000
Stück, ihre Länge lag zwischen wenigen Zeilen bis hin zu 150 Seiten. Weiterführende
Informationen bezüglich der Performance finden sich in [CROFT92].
Die Aufgaben von INQUERY bestehen im Aufbau des Inferenznetzes und in der
Anwendung des Netzes zur Wiedergewinnung der gesuchten Information.
3.6.1. Inferenznetze
Inferenznetze dienen der Repräsentation, sowohl des Informationsinhalts der Datenbasis,
als auch der Repräsentation des Informationsbedürnisses des Benutzers.
Diese Organisationsform erlaubt es, verschiedene Informationen in eine einzige Datenstruktur
zu integrieren. Das Inferenznetz zur Repräsentation des Informationsinhalts
wird im folgenden Inhaltsnetz genannt, das Inferenznetz zur Repräsentation
des Informationsbedürfnis Anfragenetz. Abbildung 2.6. zeigt ein einfaches Inferenznetz,
bestehend aus Inhalts– und Anfragenetz.
Die von probabilistischen Systemen benutzten Dokument-Retrieval-Inferenznetze
sind ein spezieller Typus der sogenannten Bayes Netze. Mathematisch handelt es
sich bei den Bayes Netzen um gerichtete, azyklische Graphen [CHAR91]. Für ihre
Handhabung stehen effiziente Graphalgorithmen zur Verfügung.
40

d1 d2 d3 di
Inhaltsnetz
w1 w2 w3 wm
i1 i2 i3
in
Anfragenetz
q
Abbildung: 2.6.
Inferenznetz aus Inhalts- und Anfragenetz
3.6.1.1. Inhaltsnetz
Das Inhaltsnetz repräsentiert den Inhalt einer Datenbasis. Typischerweise ist die Datenbasis
eine Volltextdatenbank, der Inhalt der Datenbasis die einzelnen Volltexte
oder Dokumente. Der Informationsinhalt eines Dokuments ist im einfachsten Fall
die Menge der gewichteten Begriffe, die der Verfasser des Dokuments gewählt hat.
In Anlehnung an diesen anschaulichen Fall sind im Inhaltsnetz in der Abbildung 2.6.
Dokumentknoten mit der Bezeichnung d 1 bis d i sowie Begriffsknoten (Wörter) mit
der Bezeichnung w 1 bis w m dargestellt. Eine Kante zwischen einem Dokumentenknoten
d und einem Begriffsknoten w besteht dann, wenn dieser Begriff im Dokument
von Relevanz ist. Ein Maß für die Relevanz läßt sich durch Kantenbewertungen
P(w,d) zum Ausdruck bringen.
P(w, d) g(w, d)
Für die Relevanzbemessungsfunktion g sind viele Realisierungen denkbar. Die
Spanne reicht von einer einfachen Vorkommenshäufigkeit bis hin zu wissensbasier-
41

ten Algorithmen, welche zum Beispiel Kontext, Synonyme oder unterschiedliche
Sprachen berücksichtigen. An dieser Stelle soll als Beispiel eine Wichtigkeitsfunktion
angegeben werden, die die relative Häufigkeit eines Wortes zugrunde legt. Im
Kapitel 4.2.3.1. finden sich weitere Wichtigkeitsfunktionen.
g(w, d)
count(w, d)
len(d)
Zur Definition der Funktionen count und len benutzten wir die Listennotation.
count(w, d) 0 falls d
1 count(w, tail(d)) falls head(d) w
count(w, tail(d)) sonst
0 falls d
len(d)
1 len(tail(d)) sonst
Das Inhaltsnetz ist statisch, solange sich der Inhalt der Datenbasis nicht ändert. Das
Netz wird darum nicht bei jeder Anfrage generiert, sondern nur einmal. Die Generierung
des Inhaltsnetzes geschieht durch das Parser-Subsystem (s Kapitel. 3.6.2.).
3.6.1.2. Anfragenetz
Die Repräsentation des Benutzerinteresses leistet das Anfragenetz. Suchwörter werden
zu Knoten des Anfragenetzes, Dringlichkeitswerte zu Kantenbewertungen.
Weitere Knoten im Anfragenetz ergeben sich aus Verknüpfungsoperatoren.
Wie in Abbildung 2.6. zu sehen ist, sind Anfrage– und Inhaltsnetz durch Kanten verbunden.
Im Gegensatz zum abgebildeten Beispiel können Inhalts– und Interessenknoten
auch mehrfach verbunden sein.
42

Opel VW Stadtbus ICE Fahrrad
PKW öffentliches Verkehrsmittel Sportgerät
Transportmittel
Abbildung: 2.7.
Zusätzliche Abstraktionsebenen
Abbildung 2.7. zeigt ein einfaches Beispiel für die Organisation von Begriffen in
weiteren Abstraktionsebenen. Wie man am Beispiel Fahrrad sieht, kann ein spezieller
Begriff durchaus verschiedenen, abstrakteren Begriffen in verschiedenen Abstraktionsebenen
zugeordnet sein. Eine Anfrage mit dem Suchwort ’PKW’ hätte eine
Verbindung des Interessenknotens PKW mit den Inhaltsknoten ’Opel’ und ’VW’,
also eine Mehrfachverbindung zur Folge.
Da wir aber bei unserem vereinfachten inhaltsspezifizierendem Begriff zusätzliche
Abstraktionsebenen ausgeschlossen haben, haben wir es lediglich mit
Eins-zu-Eins-Verbindungen an der Schnittstelle zwischen Inhalts– und Anfragenetz
zu tun.
Die Erkennung der Zugehörigkeit eines Begriffes zu einer Abstraktion ist ein keineswegs
triviales Problem. Hier sind Methoden der KI oder menschliche Bearbeitung
angesprochen. Im Abschnitt 3.6.2.4. werden einige einfache Begriffserkenner
vorgestellt, darüber hinaus soll dieses Thema im Rahmen dieser Arbeit nicht weiter
vertieft werden.
3.6.2. Das Parser Subsystem
Beim Aufbau des Inhaltsnetzes lassen sich verschiedene Phasen unterscheiden, die
eine Folge von Dokumenten zu Einträgen in verschiedenen Datenbanken verarbeiten.
Abbildung 2.8. zeigt das Zusammenspiel der Komponenten. Die folgenden Abschnitte
erklären die Teilaufgaben im Detail.
43

Dokument–
anfang
Dokument–
ende
... The Panel discussion ... c c c c c .... of PV electricity. ccc ... ccc ...
Dokument in spezifischem Format
lexikalische Analyse
Dokument in kanonischem Format
... c c c c ... The Panel discussion ... c c c c c .... of PV electricity. c c c ... c c c ....
Datenbank–
generator
Dokumenten
Datenbank
syntaktische
Analyse
Tokenreihe
panel discuss ..... pv electr
EOS
EOD
Begriffs–
erkenner
Begriffs
Datenbank
Transitions–
manager
Transitions
Datenbank
Abbildung: 2.8.
Das Parser Subsystem
3.6.2.1. Die lexikalische Analyse
Dieser Arbeitsschritt erhält als Eingabe eine Folge von Dokumenten, die in einem
vom System unterstützten Format vorliegen müssen. INQUERY verarbeitet gegenwärtig
sechs verschiedene Formate, d.h. es beinhaltet sechs verschiedene lexikalische
Parser, die auf die jeweiligen Formate zugeschnitten sind. Ergebnis der lexikalischen
Analyse ist eine Folge von Dokumenten in kanonischem Format. Die
folgenden Arbeitsschritte können damit systemunabhängig arbeiten.
3.6.2.2. Die syntaktische Analyse
Aus der Folge von kanonischen Dokumenten wird in diesem Schritt eine Tokenreihe
generiert. Tokens sind die kleinsten Informationseinheiten, aus denen die Dokumente
zusammengesetzt sind. Neben Worttokens existieren auch Tokens für Feldbegrenzungen.
In Abbildung 2.8. sind als Beispiel ein Token für Satzende (EOS) und eines
für Dokumentende (EOD) zu erkennen.
44

Neben der Identifizierung der Tokens leistet die syntaktische Analyse weitere Aufgaben.
Großbuchstaben werden zu Kleinbuchstaben konvertiert. Semantisch überflüssige
Wortenden werden entfernt (z.B. wird aus ’discussion’ ’discuss’). Anhand
einer Stopwortliste werden unerwünschte Wörter ausgefiltert (z.B. ’a’, ’and’, ’of’,
’the’ usw.).
3.6.2.3. Die Dokumentendatenbank
Parallel zur syntaktischen Analyse fügt ein Datenbankgenerator die Dokumente in
eine Dokumentendatenbank ein. Die Information eines Dokuments wird verschiedenen
Feldern zugeordnet, die durch spezielle Markierungen unterschieden werden
können. Eine Markierung besteht aus einer einzelnen Zeile, die aus einem Punkt
(’.’), gefolgt von einem einzelnen Großbuchstaben, besteht .
.I externe Dokumentnummer (s. 3.6.4.1.5.)
.T Dokumenttitel
.W Kurzbeschreibung (Abstract)
.B Titelaufnahme
.A Verfasser
.K Schlüsselbegriffe
.C Kategorie
.N Erfassungsdatum
.X Mehrzweckfeld
Abbildung: 2.9.
Feldmarkierungen der Dokumentdatenbank
3.6.2.4. Die Begriffserkenner
Begriffserkenner haben die Aufgabe, bestimmte Begriffsklassen zu erkennen. Gegenwärtig
verfügt INQUERY über Erkenner für die Klassen Zahl, Datum, Personennamen,
Firmennamen, Satz– und Absatzenden.
Das Erkennen von Begriffsklassen kann oftmals zu komplexen Problemstellungen
führen. So muß zum Beispiel der Zahlenerkenner Begriffe wie ’1 million’,
’1000000’ und
’1,000,000’ als gleiche Zahl erkennen. Daten können ebenfalls in verschiedenen
Schreibweisen vorliegen. ’Monday, November 29 th , 1993’ und 29.11.1993 sind
gleiche Begriffe. Firmennamen lassen sich an Bezeichnungen wie ’Co’, ’Inc’, ’Ltd’
oder ’SpA’ erkennen.
Prinzipiell sind der Anzahl und der Komplexität von Begriffserkennern keine Grenzen
gesetzt. Ihr Einsatz erhöht jedoch den zeitlichen Aufwand des Parsens beträchtlich.
Die obengenannten Erkenner verlangsamen den Parserprozeß zum Beispiel um
25%.
45

Alle Begriffserkenner liegen als Grammatik vor, so daß systemunabhängig und automatisch
die passenden Parser generiert werden können. Dadurch sind Effizienz
und Portabilität gewährleistet. Konkret liegen die Grammatiken im LEX–Format
vor. LEX ist ein standardisiertes Werkzeug in UNIX Umgebungen, welches aus einer
formalen, kontextfreien Grammatik den Quellcode eines endlichen Automaten
generiert [LEX79, MAU89].
3.6.2.5. Die Begriffsdatenbank
Die Begriffserkenner liefern als Ergebnis attributierte Begriffe in einem einheitlichen
Format. Basis des Formats sind aber immer noch Zeichen– und Ziffernfolgen,
deren Handhabung wenig effizient ist. In der Begriffsdatenbank verwaltet INQUE-
RY darum Datensätze, die jedem Begriff eine eindeutige Nummer zuordnen. Vergleiche
zwischen Begriffen sowie Verweise können so schneller und platzsparender
realisiert werden.
3.6.2.6. Der Transitionsmanager
Der Transitionsmanager registriert jeden identifizierten Begriff. Bei Erreichen des
Dokumentenendes hat der Transitionsmanager Kenntnis über Vorkommenshäufigkeit
und Position eines jeden Begriffs des Dokuments. Diese Information wird in der
sogenannten Transitionsdatenbank festgehalten.
3.6.2.7. Die Transitionsdatenbank
Für jeden Begriff in jedem Dokument existiert ein Eintrag in der Transitionsdatenbank,
der Begriff und Dokument identifiziert, sowie Auskunft über Vorkommenshäufigkeit
und Position des Begriffs gibt.
Die Gesamtheit der Transitionen spiegelt die Topologie des Inhaltsnetzes der Datenbasis
wieder. Jede Kante im Inhaltnetz entspricht einem Datensatz in der Transitionsdatenbank.
Die Häufigkeits– und Positionsinformation ist die Kantenbewertung.
46

Inhaltsnetz
Transitionsdatenbank
w2
w1
d1
d2
w3
(f 32 , p, p, p, ...)
d3
w 1 , d 1 , f 11 , p, p, p, ...
w 1 , d 2 , f 12 , p, p, p, ...
w 2 , d 1 , f 21 , p, p, p, ...
w 3 , d 1 , f 31 , p, p, p, ...
w 3 , d 2 , f 32 , p, p, p, ...
w5
d4
w4
d6
w6
d5
w 7 , d 7 , f 77 , p, p, p, ...
d7
w7
Abbildung: 2.10.
Inhaltsnetz und Transitionsdatenbank
Das INQUERY Inhaltsnetz ist ein gerichteter, azyklischer Graph, wie er im Abschnitt
3.6.1.beschrieben wurde. Die Richtung der Kanten verläuft immer von Dokumentknoten
zu Begriffsknoten. Da zu einem Dokumentknoten immer nur Begriffsknoten
benachbart seien können und umgekehrt zu einem Begriffsknoten
immer nur Dokumentknoten, ist die Zyklenfreiheit gewährleistet.
Zur Kantenbewertung im Inhaltsnetz wird von INQUERY noch keine der angesprochenen
Gewichtungsfunktionen angewendet. Durch die Markierung der Kanten mit
Vorkommenshäufigkeit und Position bleiben so verschiedene Optionen offen.
Das Inhaltsnetz in Abbildung 2.10. ist lediglich zweistufig, da es lediglich Dokumenten–
und Begriffsknoten beinhaltet. Zweistufige Inhaltsnetze haben in der praktischen
Anwendung die größte Bedeutung. Weitere Abstraktionsebenen können jedoch
konsistent in das Inhaltsnetz integriert werden. Beispielsweise kann einer
Gruppe von Begriffen, die eine gemeinsame Eigenschaft aufweisen, ein gemeinsamer
Vaterknoten vorangestellt werden, der Begriffsträger der gemeinsamen, abstrakteren
Eigenschaft ist.
47

3.6.3. Das Retrieval-Subsystem
Das Retrieval-Subsystem wandelt zunächst eine Benutzeranfrage in ein Anfragenetz
um. Die INQUERY Retrieval-Maschine evaluiert Anfrage– und Inhaltsnetz
und liefert als Ergebnis eine Liste von Dokumenten mit zugeordneter Bewertung.
3.6.3.1. Aufbau des Anfragenetzes
Anfragen können für INQUERY in einer speziellen, strukturierten Anfragesprache
formuliert werden, die dem Benutzer eine exakte Formulierung seines Informationsbedürfnisses
erlaubt.
Als zweite Möglichkeit steht eine quasi natürlichsprachliche Anfragestellung zur
Verfügung, die weit weniger exakt ist, dafür aber nur ein Minimum an formalen Anforderungen
an die Formulierung der Anfrage stellt. Anfragen in dieser Form werden
von der Retrieval-Maschine in Ausdrücke der zuerstgenannten Anfragesprache
übersetzt. Beide Formen können auch gemischt auftreten.
Aus einem Anfrageteil in natürlichsprachlicher Form werden zunächst mit Hilfe des
Parsers die Begriffe extrahiert. Die Begriffe werden dann OR–verknüpft und als Gesamtheit
mit dem Mittelwert ihrer Gewichte gewichtet.
Anfragen in der strukturierten Anfragesprache können direkt in das Anfragenetz abgebildet
werden. Begriffe und Operatoren werden zu Knoten im Anfragenetz. Die
Verbindung zwischen Anfragenetz und Inhaltsnetz geschieht über die Begriffsknoten.
#and
#or
AND–Verknüpfung
#and(A B) Wörter A und B müssen beide vorkommen
OR–Verknüpfung
#or(A B) A oder B muß vorkommen
#not Negation
#not(A) A darf nicht vorkommen
#sum Mittelwert der Dringlichkeiten der Argumente
#wsum Summe der gewichteten Dringlichkeiten. Gewichtung erfolgt
durch Summe der Gewichte und durch Benutzerangabe
#n Suchspannweite für Wortfolgen
#3(A B) wird von den Wortfolgen
”A B”, ”A c B” und ”A c c B” erfüllt.
#phrase
#syn
Satzerkenner
Sucht nach kompletten Sätzen
Synonymdeklarator
#syn(A B) A und B sind Synonyme
Die Abbildung der Anfrage in das Inhaltsnetz erhält die Klammerungsstruktur des
Anfrageausdrucks. Den so entstehenden gerichteten, azyklischen Graphen kann
48

man als invertierten Baum auffassen [CROFT91 S.193]. Er verfügt über nur ein
Blatt, welches mit dem Grad der Befriedigung des Benutzerinteresses korrespondiert.
Wurzeln hat der invertierte Baum mehrfach. Jeder Wurzelknoten korrespondiert
mit einem inhaltsspezifizierenden Begriff. Die gesamtheit der Wurzelknoten
definiert das Benutzerinteresse.
#or (#and(A #or(B C) #not(D)) E)
A
B
C
D
E
or
not
and
or
Abbildung: 2.11.
Beispiel eines Anfragenetzes
Abbildung 2.11. zeigt eine einfache Anfrage und deren Abbildung in einen invertierten
Baum. Die Wurzeln des Baumes sind die Suchwörter A, B, C, D und E. Die
inneren Knoten des Baums enthalten die Operatoren der Anfragesprache. Eine
Klammerungsebene des Anfrageausdrucks entspricht einem Teilbaum. Das Blatt
des Baumes entspricht der Gesamtanfrage und damit dem Informationsbedürfnis
des Benutzers.
3.6.3.2. Die Retrieval-Maschine
Die INQUERY Retrieval-Maschine erhält das Anfragenetz als Eingabe und verknüpft
dieses zunächst mit dem Inhaltsnetz. Im nächsten Schritt wird der Interessenerfüllungsgrad
des Anfragenetzes bestimmt. Dazu wird als initiale Bewertung eines
Suchwortknotens die Wahrscheinlichkeit bestimmt, mit der dieser das
Informationsbedürfnis erfüllt, unter der Annahme, daß alle Dokumente in der Auswahl
gleich zutreffend sind.
Nun werden der Reihe nach alle Dokumente der Auswahl observiert. Jeder bearbeitete
Dokumentknoten wird markiert und dessen Bewertung durch das Netz propagiert.
Es wird somit die bedingte Wahrscheinlichkeit berechnet, daß das Interesse
49

des Benutzers durch das untersuchte Dokument erfüllt wird. Sind alle Dokumente
der Auswahl abgearbeitet, lassen sie sich in eine Rangfolge sortieren, die ihren Interessenerfüllungsgrad
wiederspiegelt.
Im Laufe des Berechnungsvorgangs muß für jeden inneren Knoten eine Bewertung
aufgrund der Bewertung seiner Vorgängerknoten abgeschätzt werden. In Abbildung
2.12. sind die Berechnungsformeln für die Knoten des Anfragenetzes wiedergegeben.
Die Wahrscheinlichkeit, daß der Knoten Q das Informationsbedürfnis des Benutzers
erfüllt, wird als bel(Q) (engl. belief) bezeichnet. Die Berechnung von bel(Q)
ist vom Typ des Knotens Q abhängig. Mit p i sind die Bewertungen der i Vorgängerknoten
von Q bezeichnet, mit w i deren Wichtigkeit. Eine genauere Erläuterung der
Formeln, sowie Berechnungsmethoden für boolesche Bewertungen finden sich in
[CROFT91].
bel not (Q) 1 p 1
bel or (Q) 1 (1 p 1 ) ... (1 p n )
bel and (Q) p 1 p 2 ... p n
bel max (Q) max(p 1 , p 2 , ... ,p n )
bel sum (Q) p 1 p 2 ... p n
n
bel wsum (Q) (w 1 p 1 w 2 p 2 ... w np n ) w q
w 1 w 2 ... w n
Abbildung: 2.12.
Evaluierung der Knoten des Anfragenetzes
Ein Wurzelknoten des Anfragenetzes hat einen Begriffsknoten des Inhaltsnetzes als
Vorgänger. Als Berechnungsvorschrift für dessen Bewertung schlagen Croft und
Turtle in [CROFT91] folgende Formel vor:
bel(Q) w p i parents(Q) w q
w p
p parents(Q)
Q ist in diesem Fall vom Typ Begriffsknoten und damit sind die Vorgänger von Q
(parents(Q)) alle Dokumentknoten. Die Berechnung wird durchgeführt, wenn der
Vorgänger p i von Q observiert wird. w p ist das Gewicht des Knotens p.
50

3.6.4. Schnittstellen
INQUERY bietet drei verschiedene Interaktionsschnittstellen. Eine Schnittstelle für
Anwendungsprogramme erlaubt die Anbindung an andere Programme oder die Entwicklung
eigener Benutzerschnittstellen. Eine interaktive Benutzerschnittstelle erlaubt
direkte Arbeit mit dem System. Als dritte Zugriffsmethode besteht die Möglichkeit
INQUERY über eine Batchdatei nicht interaktiv zu steuern. Auf die
Darstellung der Fähigkeiten der interaktiven– und der Batch Schnittstelle wird nicht
weiter eingegangen, da diese für die vorliegende Arbeit nicht von Bedeutung sind.
Etwas detaillierter wird dafür im folgenden die Funktionaliät der Schnittstelle für
Anwendungsprogramme vorgestellt.
3.6.4.1. Application Programmers Interface
Das Application Programmers Interface (API) ist eine Funktionsbibliothek, die Anwendungsprogrammen
den Zugriff auf das INQUERY Retrieval-System erlaubt.
opendb void
opendb(dbinfo *db);
closedb
inq_num_docs_in_collection
void
closedb(dbinfo *db);
long int
inq_num_docs_in_collection
(void);
eval_query belieflst *
eval_query (char *query,
void (*feedback_function)());
externalToInternalID
int
externalToInternalID
(char *externalID);
internalToExternalID char *
internalToExternalID
(int internalID);
get_doc
int
get_doc (int id, int mode);
did char *
did (void);
dsource char *
dsource (void);
dtitle char *
dtitle (void);
öffnet Datenbank
schließt Datenbank
liefert Anzahl der Dokumente
der Datenbank
evaluiert Anfrage
wandelt externe Dokumentnummer
in interne
Dokumentnummer
wandelt interne Dokumentnummer
in externe
Dokumentnummer
liefert Inhalt eines Dokuments
liefert externe Dokumentnummer
liefert Autor des Dokuments
liefert Dokumenttitel
51

dtext char *
dtext (void);
new_dbinfo
dbinfo*
new_dbinfo
(char *dbname, char *outdir,
char *stopname,
char *relnamefloat bel,
float tf, int batchflag);
liefert Dokumenttext
erzeugt und initialisiert
eine neue Instanz der
dbinfo Struktur
Abbildung: 2.13.
Funktionen des Application Programmers Interface
3.6.4.1.1. opendb
void opendb(dbinfo *db);
Diese Funktion öffnet eine Datenbank für den anschließenden Zugriff. Es können
nicht mehrere Datenbanken gleichzeitig geöffnet sein. Ist Zugriff auf verschiedene
Datenbanken gewünscht, so muß vor Öffnen einer neuen Datenbank die aktuell geöffnete
geschlossen werden.
Das Argument db ist die Adresse einer Variablen vom Typ dbinfo. Die Variable db
muß mit den gewünschten Werten initialisiert sein (s. Funktion new_dbinfo).
3.6.4.1.2. closedb
void closedb(dbinfo *db);
Schließt die vorher mit opendb(db) geöffnete Datenbank. Der belegte Speicher wird
freigegeben. Falls der Zugriff in Batch–Betriebsart geschah, wird durch closedb das
Suchergebnis in die Ergebnisdatei eingestellt.
3.6.4.1.3. inq_num_docs_in_collection
long int inq_num_docs_in_collection(void);
Diese Funktion liefert die Anzahl der Dokumente in der geöffneten Datenbank.
3.6.4.1.4. eval_query
belieflst *eval_query (char *query, void (*feedback_function)());
Die eval_query Funktion ist das Herzstück des API. Sie erhält im Argument query
eine Anfrage als Text, generiert daraus das Anfragenetz und wertet es aus. Der Rück-
52

gabewert belief_lst ist eine Liste mit den als relevant befundenen Dokumenten und
deren Relevanzwerten.
Struktur belief_lst
default_belief float default_belief Defaultwert für Dokumentbewertung
term_freq int term_freq Gegenwärtig nicht benutzt
doc_cnt int doc_cnt Anzahl der Elemente des
Vektors
list belief_elt *list Vektor aus belief_elt
Abbildung: 2.14.
Felder der Struktur belief_lst
Die Struktur belief_lst beinhaltet im wesentlichen einen Vektor aus Elementen vom
Typ belief_elt und die Information, aus wievielen Elementen der Vektor besteht. Die
belief_elt-Elemente enthalten die Zuordnung von Dokumentennummer und Bewertung
des Dokuments. Die Elemente sind nach der Bewertung sortiert, das Dokument
mit der höchsten Bewertung steht an der ersten Stelle.
Struktur belief_elt
doc_id int doc_id interne Dokumentnummer
belief float belief Bewertung des Dokuments
(s. Kapitel
3.6.3.2.)
Abbildung: 2.15.
Felder der Struktur belief_elt
Als feedback_function kann eine Funktion angegeben werden, die von eval_query
nach jeder Termevaluierung aufgerufen wird. Als Parameter wird ihr die Anzahl der
noch zu bearbeitenden Terme übergeben. Das aufrufende Programm kann sich so
über den Fortschritt der Arbeit informieren lassen. Wir keine feedback_function gewünscht,
so kann an ihrer Stelle auch NULL angegeben werden.
3.6.4.1.5. externalToInternalID
int externalToInternalID(char *externalID);
Diese Funktion wandelt die externen Dokumentennummern in die intern benutzte
Nummerndarstellung um. Die externe Nummer liegt als Zeichenfolge in der Dokumentendatenbank
vor. Sie wird im .I-Feld abgelegt (s. Abbildung 2.9.). Die Dar-
53

stellung der internen Nummer durch den Typ int dient einer effizienteren Handhabung.
3.6.4.1.6. internalToExternalID
char *internalToExternalID(int internalID);
Diese Funktion liefert die umgekehrte Umwandlung diesmal von der internen Nummer
zur externen Dokumentnummer.
3.6.4.1.7. get_doc
int get_doc(int id, int mode);
Diese Funktion erlaubt den Zugriff auf den Inhalt eines Dokuments. Das Argument
id gibt die Nummer des gewünschten Dokuments an. Mit mode wählt man die gewünschte
Betriebsart. Es stehen drei verschidene Betriebsarten zur Verfügung, die
den Umfang der gewünschten Information spezifizieren:
ID nur externe Dokumentnummer
HEADING Dokumentnummer, Titel, und Quelle (Autor)
ALL gesamtes Dokument, d.h. HEADING und Text
Die Funktion kopiert den gewünschten Text in einen internen Puffer und gibt die
Länge des Textes als Rückgabewert zurück. Die folgenden Funktionen liefern die
Einträge des Puffers.
3.6.4.1.8. did
char *did(void);
Diese Funktion liefert die externe Nummer des letzten mit get_doc observierten Dokuments.
Falls dieses Dokument über keinen Dokumentnummerneintrag verfügte,
wird der String ’id missing’ zurückgegeben.
3.6.4.1.9. dsource
char *dsource(void);
Diese Funktion liefert die Quelle (den Autor) des letzten mit get_doc observierten
Dokuments. Falls dieses Dokument über keinen Quelleneintrag verfügte, wird der
String ’source missing’ zurückgegeben. Die Betriebsart von get_doc muß dabei die
Quelle eingeschlossen haben.
54

3.6.4.1.10. dtitle
char *dtitle(void);
Diese Funktion liefert den Titel des letzten mit get_doc observierten Dokuments.
Falls dieses Dokument über keinen Titeleintrag verfügte, wird der String ’title missing’
zurückgegeben. Die Betriebsart von get_doc muß dabei den Titel eingeschlossen
haben.
3.6.4.1.11. dtext
char *dtext(void);
Diese Funktion liefert den Text des letzten mit get_doc observierten Dokuments.
Falls dieses Dokument über keinen Texteintrag verfügte, wird der String ’document
body missing’ zurückgegeben. Die Betriebsart von get_doc muß dabei den Text eingeschlossen
haben.
3.6.4.1.12. new_dbinfo
dbinfo *new_dbinfo(char *dbname, char *outdir, char *stopname,
char *relname
float bel, float tf, int batchflag);
Die Funktion new_dbinfo erzeugt eine neue Instanz der dbinfo Struktur und initialisiert
die Felder der Struktur mit den als Argumenten übergebenen Werten.
Struktur dbinfo
dbname char dbname[] Pfadname der Datenbankdatei
ohne Extension
outdir char outdir[] Pfadname der Directory
für Ausgabedateien
stopname char stopname[] Pfadname der Stopwortdatei.
NULL, falls keine
Stopwortdatei benutzt
wird
relname char relname[] Pfadname der Relevanzdatei.
NULL, falls keine
Relevanzdatei erwünscht
ist
bel float bel Defaultwert für belief
55

tf float tf Defaultwert für Termfrequenz
batchflag int batchflag Schalter für Batchbetriebsart
Abbildung: 2.16.
Felder der Struktur dbinfo
Die Einträge in den Feldern von dbinfo können auch nachträglich geändert werden.
Folgende Funktionen stehen dazu zur Verfügung:
int set_db_name(dbinfo *db, char *name);
int set_db_stopname(dbinfo *db, char *stname);
int set_db_relname(dbinfo *db, char *rlname);
int set_db_outdir(dbinfo *db, char *outdir);
int set_db_tf(dbinfo *db, int newtf);
int set_db_bel(dbinfo *db, newbel);
int set_db_batch_mode(dbinfo *db, int mode);
Welche Felder der dbinfo-Struktur von den Funktionen verändert werden, ist selbserklärend.
Der Rückgabewert ist 0, wenn die Funktion erfolgreich war oder –1,
wenn ein Fehler auftrat.
56

4. Entwurf der Benutzerschnittstelle
Aus Sicht des Benutzers besteht der Retrievalprozeß aus Suchdialog und Präsentation
der Ergebnismenge. In diesem Kapitel werden diese beiden Bestandteile analysiert
und ein Entwurf für eine interaktive, dreidimensionale Benutzerschnittstelle erarbeitet.
4.1. Visualisierung des Suchdialogs
In der Regel besteht der traditionelle Suchdialog zwischen Benutzer und Retrieval-
System aus einer Folge von Informationsanforderungen und Informationsangeboten
durch das System. Die spezifischen Ausprägungen der einzelnen Äußerungen
im Dialog richten sich nach dem Informationsbedürfnis des Benutzers und nach dem
Inhalt der Datenbank. In jedem Dialogschritt findet also entweder eine Informationssuche
des Systems oder eine Relevanzeinschätzung des Benutzers statt, anhand
der er seine nächste Anfrage gestaltet [HEMMJE92].
Der Suchdialog zwischen Benutzer und Retrieval-System ist ein iterativer Prozeß,
bei dem der Benutzer durch schrittweise Modifikation seiner Anfrage die Ergebnismenge
solange beeinflußt, bis sie seinem Informationsbedürfnis entspricht. Im theoretischen
Idealfall liefert jeder Iterationsschritt eine Verbesserung des Erfüllungsgrades
des Benutzerinteresses, bis nach Überschreiten eines Interessenerfüllungsgrenzwertes
der Prozeß abgebrochen wird.
In der Praxis besteht jedoch keine Garantie dafür, daß sich ein Retrieval-System in
dieser idealen Weise verhalten wird. So können zwei für den Benutzer subjektiv sehr
ähnliche Anfragen zu gänzlich verschiedenen Ergebnismengen führen und umgekehrt
zwei subjektiv stark verschiedene Anfragen eine identische Ergebnismenge
zur Folge haben. Da Benutzerinteresse und Informationsinhalt nicht eindeutig quantifizierbar
sind, bleibt dem Benutzer so immer die Unsicherheit, in der Datenbank
vorhandene und relevante Information nicht erhalten zu haben. Die Anforderungen
an ein Retrieval-System bestehen darum nicht nur aus einer möglichst leistungsfähigen
Retrieval-Maschine, sondern auch in einer Benutzerführung, die eine möglichst
sichere Erschließung der Leistungsfähigkeit der Retrieval-Maschine erlaubt.
In diesem Kapitel wird das Modell eines Interaktionswerkzeuges vorgestellt, welches
räumliche Strukturen als Metapher heranzieht, um den Suchdialog für den Benutzer
intuitiv erfaßbar und kontrollierbar zu machen.
4.1.1. Inhaltsorientierte Suche
Die Unterstützung der Intuition des Benutzers ist maßgebend für die Gestaltung eines
visuellen Suchdialogs. An erster Stelle der wünschenswerten Fähigkeiten steht
57

die Befreiung von der Notwendigkeit, die internen Strukturen des Retrieval-Systems
zu kennen, um erfolgreich Suchanfragen stellen zu können. Mit anderen Worten,
der Benutzer sollte in die Lage versetzt werden, den Inhalt einer Datenbank zu
untersuchen, indem er inhaltsorientierten und nicht organisatorisch orientierten
Suchpfaden folgt. Räumliche, visuelle Strukturen sollen dem Benutzer den Informationswiedergewinnungsprozeß
nachvollziehbar machen und ihm eine Orientierung
im Informationsinhalt der Datenbank ermöglichen. Ziel ist es, eine Metapher
zu finden, die den Informationsinhalt einer Datenbank in eine räumliche Struktur
mit den genannten Eigenschaften abbildet.
Aus dem Bereich der zweidimensionalen, graphischen Benutzerschnittstellen sind
Metaphern wie Schreibtischoberfläche, Aktenordner, Dokument, Knopf, Schieberegler
bekannt. All diese Metaphern sind von Objekten der realen Welt abgeleitet
und geben so Aufschluß über ihre Eigenschaften und Verwendungsmöglichkeiten.
Wie aber sieht der Inhalt einer Datenbank aus? Hierbei handelt es sich um eine abstrakte
Informationsstruktur, die keine Entsprechung in Form eines Werkzeugs oder
Gegenstands der realen Welt hat. Als Ansatz für die Entwicklung einer Metapher
strukturieren wir darum zunächst die unterscheidbaren Bestandteile des Suchdialogs
in Form von Informationsmengen.
4.1.2. Informationsmengen
Während des Suchdialogs lassen sich verschiedene Informationsmengen unterscheiden.
Der Inhalt der Datenbank, die Menge aller in der Datenbank gespeicherten
Dokumente, ist die Inhaltsmenge. Die Menge aller Dokumente, die der Benutzer als
interessant einstuft, ist die Interessenmenge. Die Interessenmenge ist nicht unbedingt
eine Teilmenge der Inhaltsmenge, denn möglicherweise enthält die Datenbank
nicht die Information, die der Benutzer wünscht. Haben die Inhaltsmenge und die
Interessenmenge eine gemeinsame Teilmenge, so ist dies die Menge der relevanten
Dokumente, die das Retrieval-System wiedergewinnen soll.
Im Laufe des Retrieval-Prozeßes werden Teilmengen der Inhaltsmenge durch die
Anfragen des Benutzers zu Ergebnismengen. Die Vereinigung dieser Teilmengen
heißt im folgenden Kontextmenge. Eine Kontextmenge entsteht bei jedem Suchdialog
und verändert sich im Laufe des Dialogs. Die Benennung Kontextmenge bringt
zum Ausdruck, daß ihr Inhalt einen thematischen Zusammenhang zwischen dem Inhalt
der Datenbank und den Anfragen des Benutzers herstellt.
Da die Ergebnismenge einer Anfrage auch Dokumente beinhalten kann, die der Benutzer
als nicht relevant einstuft, ist die Kontextmenge nicht in jedem Fall auch das
Suchergebnis des Gesamtprozeßes. Außerdem ist die Interessenmenge des Benutzers
nicht unbedingt klar umrissen, da sie Dokumente enthalten kann, die für den
Benutzer sehr interessant sind, aber auch Dokumente, die das Informationsbedürfnis
nur schwach berühren. Wir führen darum eine Kernmenge ein, in die der Benutzer
alle Dokumente der Kontextmenge aufnehmen kann, die er zu einem bestimmten
58

Zeitpunkt als relevant beurteilt. Der Inhalt der Kernmenge muß in jedem Fall eine
Teilmenge der zu diesem Zeitpunkt aktuellen Kontextmenge sein, denn alle relevanten
Dokumente des bisherigen Suchprozeßes sind in ihr enthalten.
Der Zusammenhang zwischen den einzelnen Mengen wird in Abbildung 3.1. dargestellt.
In der Schnittmenge von Inhaltsmenge und Interessenmenge liegen Dokumente,
die sowohl in der Datenbank gespeichert sind, als auch für das Informationsinteresse
des Benutzers relevant sind. Durch drei verschiedene Anfragen erhielt der
Benutzer die drei Ergebnismengen t 1 bis t 3 . Ihre Vereinigung bildet die Kontextmenge.
Die Kontextmenge enthält im rechten, oberen Gebiet auch Dokumente, die nicht
im Interessensgebiet des Benutzers liegen. Auch liegen Dokumente im relevanten
Bereich, die der Benutzer noch nicht durch Anfragen in die Kontextmenge aufgenommen
hat. Einen Teil der Kontextmenge hat der Benutzer durch ein manuelles
Auswahlverfahren in den Kern aufgenommen.
Inhaltsmenge
Kontextmenge
t 2
t 3
t 1
Kern
Interessenmenge
Abbildung: 3.1.
Informationsmengen
4.1.3. Kontextbaum
Durch den iterativen Suchdialog erarbeitet sich der Benutzer die Kontextmenge. Für
die Erfaßbarkeit des Suchdialogs sind weniger die Elemente der Kontextmenge wesentlich,
sondern in erster Linie die Ursache ihrer Aufnahme in die Menge. Die Visualisierung
muß also besonderen Wert auf die intuitive Wiedererkennbarkeit der
einzelnen Dialogschritte legen.
59

Ein Dialogschritt besteht aus einer Anfrage und dem anschließenden Hinzufügen
des Anfrageergebnisses zur Kontextmenge. Die Anfrage ergibt sich aus der bisherigen
Entwicklung des Dialogs. Eine Zuordnung von Anfrage und verursachter Ergebnismenge
wird umso einfacher, je einfacher die Anfrage ist. Im elementaren Fall
besteht eine Anfrage aus einem inhaltsspezifizierenden Begriff und die zugehörige
Ergebnismenge aus allen Dokumenten, in denen dieser Begriff von Relevanz ist.
Gleichzeitig benötigt man für eine derart elementare Anfrage keine komplexe Anfragesprache.
Dem Benutzer muß lediglich die Angabe eines inhaltsspezifizierenden
Begriffs ermöglicht werden.
Eine elementare Anfrage mit einem Begriff erfüllt unsere Anforderungen bezüglich
intuitiver Erfaßbarkeit und Inhaltsorientierung. Andererseits bedeuten elementare
Anfragen den Verzicht auf das mächtige Mittel der Suchanfragen in Anfragesprachen
mit booleschen Operatoren. Wir werden jedoch sehen, wie dem Benutzer durch
das Werkzeug der Relevanzkugel die Mächtigkeit einer Anfragesprache zurückgegeben
wird.
Zunächst betrachten wir die Entwicklung des Suchdialogs auf der Basis elementarer
Anfragen. Zur Expansion der Kontextmenge steht dem Benutzer die Möglichkeit
zur Verfügung, einen Begriff als relevanten Suchbegriff zu spezifizieren. Die Kontextmenge
wird dadurch um alle Dokumente erweitert, in denen dieser Begriff von
Relevanz ist. Diese Expansion heißt Begriffsexpansion. Weiter wird dem Benutzer
anhand der bisherigen Kontextmenge die Möglichkeit gegeben, neue Anfragen zu
finden, indem die Begriffe der Dokumente aus der Kontextmenge für neue Anfragen
angeboten werden. Diese Expansion heißt Dokumentexpansion. So entsteht ein
Kontextbaum, der alle Dokumente der Kontextmenge als Dokumentknoten enthält.
Jeder Dokumentknoten geht auf eine elementare Anfrage, also einen Begriff zurück.
Dieser Begriff ist im Baum in Form eines Begriffsknotens enthalten. Ein Dokument
ist mit seinem Ursprungsbegriff durch eine Kante verbunden.
60

a
A B C
b c d e f g
D
E
e h g
Abbildung: 3.2.
Kontextbaum
Ein Beispiel eines möglichen Kontextbaumes ist in Abbildung 3.2. dargestellt. Die
Kleinbuchstaben stellen Begriffsknoten dar, große Buchstaben Dokumentknoten.
Im Beispiel beginnt der Benutzer die Suche mit dem Begriff a. Die erste Kontextmenge
beinhaltet die Dokumente A, B und C. Der Benutzer wählt Dokument B für
eine Dokumentexpansion und erhält die Begriffe b und c; b und c sind die relevanten
Begriffe des Dokuments B. Mit ihnen könnte nun eine Begriffsexpansion durchgeführt
werden. Der Benutzer ist jedoch zunächst an Dokument C interessiert. Er führt
mit C eine Dokumentexpansion durch und erhält die Begriffe d, e, f und g. Mit dem
Begriff d wird eine Begriffsexpansion durchgeführt. Das Ergebnis dieser elementaren
Anfrage ist das Dokument D. Der Inhalt der Kontextmenge wird erweitert zu
A, B, C und D.
Nun expandiert der Benutzer Dokument D und erhält den Begriff e. Begriff e gehörte
aber auch schon zu den Begriffen, die durch Expansion von C aufgenommen wurden.
Dieser Effekt tritt auf, wenn in verschiedenen Dokumenten gleiche Begriffe
verwendet werden. Da eine Suche darauf abzielt, Dokumente eines gemeinsamen
Themengebiets wiederzugewinnen, kann das vermehrte Auftreten dieses Effekts als
Anzeichen für eine zielgerichtete Entwicklung des Suchdialogs gewertet werden.
Schließlich bedeuten gleiche Begriffe in verschiedenen Dokumenten eine thematische
Verwandtschaft der Dokumente (s. Kapitel 3.5.).
Um den Baum konsistent zu halten, muß geregelt werden, wie eine Expansion des
Begriffs e behandelt wird. Da e im Baum zweimal vorkommt, kann der Suchdialog
an zwei verschiedenen Stellen fortgesetzt werden, wobei die erzeugten Unterbäume
in beiden Fällen identisch wären. Eine unabhängige Behandlung der Knoten könnte
zu unnötig komplexen Bäumen führen, deren teilweise identische Unterbäume
nichts zur Entwicklung der Kontextmenge beitragen. Eine Expansion sollte folglich
61

nur an einem der beiden Knoten möglich sein. Im folgenden wird von der Konvention
ausgegangen, daß ein Unterbaum, der zu einem mehrfach vorkommenden Knoten
gehört, jeweils an denjenigen Knoten angehängt wird, der im Laufe der Suche
zuerst auftrat. Im Beispiel expandiert der Benutzer den doppelten Begriffsknoten e
und erhält den Dokumentknoten E. Knoten E wird an den ersten Knoten e angehängt.
4.1.4. Visualisierung von Bäumen
Die zweidimensionale Darstellung von vernetzten Informationsstrukturen ist weit
verbreitet und leicht erfaßbar. Beispielsweise ist uns die Visualisierung von geographischen
Informationen in Form von Landkarten derart vertraut, daß wir sie intuitiv
für ein Abbild der Landschaft halten. Tatsächlich sieht eine Luftaufnahme der Landschaft
völlig anders aus.
Die Darstellung von hierarchisch vernetzten, baumartigen Informationsstrukturen,
zu denen auch der Kontextbaum gehört, ist ebenfalls weit verbreitet. Dazu gehört
zum Beispiel die Darstellung von betriebswirtschaftlichen oder politischen Hierarchiestrukturen.
Im Bereich der Informatik ist die Darstellung von Dateisystemen
oder Programmstrukturen in Folge des Einsatzes graphischer Benutzeroberflächen
verbreitet. Im Kapitel 4.15. wird beispielsweise die Visualisierung des Kontextbaums
durch einen sogenannten Szenengraphen mit Hilfe dieser Darstellungsform
verdeutlicht.
Durch die Erweiterung dieser Darstellungsform um die dritte Dimension und durch
Hinzunahme von Animation wird eine neue Qualität dieser Darstellungsform erreicht.
Information, die im Vordergrund des Benutzerinteresses steht, kann nun im
wörtlichen Sinn des Wortes im räumlichen Vordergrund gezeigt werden. Durch interaktive
Animation macht man sich die Veranlagung des menschlichen Wahrnehmungssystems
zu Nutze.
Im Rahmen des Information-Visualizer–Prototyps des Xerox Palo Alto Research
Centers wurden verschiedene Visualisierungsformen entwickelt [PARC]. Eine animierte,
dreidimensionale Visualisierungsform für Baumstrukturen, der sogenannte
”Cone Tree”, gehört ebenfalls zum System. In [ROB91] werden diese Kegelbäume
beschrieben.
Die Knoten des Baumes werden karteikartenartig als Plättchen mit Beschriftung
dargestellt. Die hierarchische Beziehung zwischen einem Knoten und seinen direkten
Nachfolgern wird durch einen Kegel symbolisiert. An der Spitze des Kegels steht
das Plättchen des Vaterknotens, an der Grundfläche des Kegels sind die Plättchen
der Sohnknoten angeordnet. Jeder Sohnknoten kann seinerseits wieder der Vaterknoten
eines untergeordneten Kegels sein. Die Konen werden transparent dargestellt,
um nicht die Sicht auf Konen im Hintergrund zu blockieren.
Ein Knoten kann selektiert werden, indem er mit der Maus angeklickt wird. Der
Kegelbaum rotiert daraufhin so, daß der ausgewählte Knoten und alle Knoten auf
62

dem Pfad zwischen ihm und der Wurzel nach vorne zeigen. Die animierte Rotation
ermöglicht es dem Benutzer, die Transformation des Baumes zu verfolgen und damit
die Orientierung zu behalten.
Die dreidimensionale Darstellung macht eine effektivere Ausnutzung des Bildschirmes
möglich. Die Darstellung des gesamten Baums ist auf einem Bildschirm bei
größeren Verzweigungsfaktoren möglich, als bei einer zweidimensionalen Darstellung.
Die Notwendigkeit, die Knotenvisualisierung zu verkleinern oder auf eine
vollständige Darstellung zu verzichten, tritt erst bei größeren Strukturen auf.
Läßt man die Größe der Knotenvisualisierungen außer Acht, so lassen sich die Größenverhältnisse
analytisch vergleichen. Wir gehen von einem Baum mit l Ebenen
und einem Verzweigungsfaktor b aus. Im zweidimensionalen Fall benötigt ein solcher
Baum eine Fläche der Größenordnung l b l–1 . Der Baum in Abbildung 3.3.
hat vier Ebenen (l=4) und einen Verzweigungsfaktor von (b=3).
In Abbildung 3.4. ist ein Baum mit gleicher Ebenenzahl und gleichem Verzweigungsfaktor
in dreidimensionaler Darstellung skizziert. Die Knotenvisualisierungen
der Elemente einer Geschwistergruppe sind nun nicht mehr nebeneinander angeordnet,
sondern ringförmig. Ein Zylinder in der Abbildung stellt einen solchen
Ring mit jeweils drei Kantenvisualisierungen auf seiner Außenfläche dar. Rechts im
Bild ist die Sicht aus der Wurzelperspektive dargestellt.
4
3 41 9
Abbildung: 3.3.
Zweidimensionaler Baum
63

( 3 1 2 )41 3
Abbildung: 3.4.
Dreidimensionaler Baum
Der Umkreis der untersten Baumebene U läßt sich aus dem Radius des ersten Rings
R 1 addiert mit dem maximalen Radius der Umkreise aller seiner Unterbäume berechnen.
Der Platzbedarf der Baumhöhe ist wie in der zweidimensionalen Darstellung von
der Größenordnung l. Der Platzbedarf der untersten Blätterebene kann durch den
Durchmesser seines Umkreises nach oben abgeschätzt werden, da mit zunehmendem
Verzweigungsfaktor der Umkreis immer dichter ausgefüllt wird. Wir gehen dabei
von der Voraussetzung aus, daß Ringe sich nicht überschneiden dürfen.
Für die analytische Herleitung des Platzbedarfs beschreiben wir einen Baum in Listennotation.
Ein Baum ist eine Liste. Ein Element der Liste ist einem Knoten des
Baums zugeordnet und besteht aus zwei Komponenten. Die erste Komponente ist
die Beschreibung des Knotens, die zweite Komponente ist die Liste des Unterbaums
des Knotens. Ist der Knoten ein Blatt, so ist die Unterbaumliste leer. Ein Baum, der
nur aus einem Knoten W besteht, hat folgende Beschreibung: . Ein etwas
komplexerer Baum und seine Listennotation sind in Abbildung 3.5. zu sehen.
64

a
A B C
b c d e f g

größter Unterbaum
Vaterkreis
Umkreis
Abbildung: 3.6.
Umkreis eines Teilbaums
Bei der Berechnung des Platzbedarfs von zweidimensionalen Bäumen sind wir von
einem konstanten Verzweigungsfaktor b und einer festen Baumtiefe von l ausgegangen.
Die Berechnung des Platzbedarfes vereinfacht sich unter dieser Voraussetzung
zu P(l)(b/ + 1/2) l–1 .
P(1) 1
b P(l 1) P(l 1)
P(l)
2
P(l 1) ( b 1 2 )
für l 1
P(l) ( b 1 2 )l1
für l
Abbildung 3.7. zeigt einen Vergleich des Platzbedarfs von zwei-- und dreidimensionalen
Bäumen bei einem Verzweigungsfaktor von 3. Der Platzbedarf wächst in beiden
Darstellungsformen exponentiell. Der Vorteil der dreidimensionalen Darstellung
liegt in einem späteren Ansteigen der Kurve.
66

P
10
2D
3D
1
1 2 3 4 5 6
l
Abbildung: 3.7.
Platzbedarfsvergleich
Die Verringerung des Platzbedarfs wird dadurch erkauft, daß nur noch wenige Knoten
frontal in Richtung Betrachter ausgerichtet sind. Die Mehrzahl der Knoten ist
perspektivisch verkürzt und zum Teil sogar mit der Rückseite in Richtung Betrachter
ausgerichtet. Vorteil der kompakten Darstellung ist die verbesserte Übersichtlichkeit
der Gesamtstruktur. Die Orientierung wird für den Betrachter vereinfacht.
Wesentliche Voraussetzung für die Effektivität der dreidimensionalen Darstellung
ist die interaktive Animation. Der Benutzer muß in die Lage versetzt werden, die
Darstellung so zu manipulieren, daß die für ihn momentan interessanten Teile des
Baums in den Vordergrund treten. So lassen sich gute Orientierungsmöglichkeit innerhalb
der gesamten Struktur und übersichtliche Darstellung des aktuellen Interesses
kombinieren.
4.1.5. Der Kontextbaum als Kegelbaum
Der Kontextbaum ist eine abstrakte Struktur, welche die Kontextmenge und Entwicklung
des Suchdialogs beinhaltet. Anhand der Stellung eines Knotens im Baum
läßt sich jederzeit sagen, welcher andere Knoten für die Aufnahme verantwortlich
war. Anhand der Geschwisterbeziehungen von Begriffsknoten läßt sich der Inhalt
eines Dokuments erfassen, anhand der Geschwisterbeziehungen von Dokumentknoten
läßt sich eine inhaltliche Verwandtschaft dieser Dokumente erfassen. Das
Konzept ist einfach nachvollziehbar und weitgehend systemunabhängig. Es verlangt
vom Retrieval-System lediglich die Fähigkeit, zu einem Begriff relevante Dokumente
und zu einem Dokument relevante Begriffe liefern zu können.
67

Mit dem Präsentationsmodell des Kegelbaums läßt sich eine räumliche Darstellung
des Kontextbaums erreichen, die alle gewünschten Eigenschaften der Struktur erhält.
Den Knoten des Baums werden visuelle Repräsentierungen zugeordnet, die
Aufschluß über Typ und Eigenschaften und Inhalt des Knotens geben. Die hierarchische
Beziehung zwischen einem Knoten und seinen Nachfolgerknoten wird
durch einen Kegel visualisiert. An der Spitze des Kegels steht die Visualisierung des
Knotens, an der Grundfläche des Kegels sind die Visualisierungen der Nachfolgerknoten
angeordnet. Jeder Nachfolgerknoten kann dabei wieder an der Spitze eines
weiteren, untergeordneten Kegels stehen.
4.1.5.1. Informationskodierung der Knoten
Die zu visualisierenden Merkmale der Knoten des Kontextbaumes sind:
Dokumentknoten oder Begriffsknoten
Original oder Verweis (bei mehrfachem Auftreten)
Name des Begriffs oder Dokuments
Der Knotenname muß textuell dargestellt werden. Handelt es sich um einen Begriffsknoten,
besteht die Visualisierung aus dem ausgeschriebenen Begriff. Handelt
es sich um einen Dokumentknoten, wird der Titel des Dokuments für die Namensvisualisierung
herangezogen.
Es ist auch denkbar, Begriffe und Dokumente durch Abbildungen zu visualisieren,
zum Beispiel um Sprachunabhängigkeit zu erreichen. Dazu wäre jedoch ein Programm
nötig, das jedem Begriff oder Dokument eine passende Abbildung in Form
eines Fotos oder Piktogramms zuordnet. Bezeichnet ein Begriff einen Gegenstand,
läßt sich leicht eine graphische Repräsentation finden. Bildliche Darstellung von abstrakten
Begriffen oder ganzen Dokumenten ist jedoch sehr schwierig und führt
schnell zu Mißverständnissen. Diese Ebene der Informationsvisualisierung ist ein
Beispiel dafür, daß ein Wort mehr sagen kann als 1000 Bilder. Sinnvoll kann eine
graphische Repräsentation aber bei nichttextuellen Datenbanken oder gegenständlichen
Informationen (Farben, Moleküle, Bilder, Warenhauskatalog, Pflanzen) sein.
Die Typeigenschaften ”Dokument” oder ”Begriff”, sowie ”Original” oder ”Kopie”
können einfacher durch graphische Attribute visualisiert werden. Form und Farbe
der Knotenvisualisierungen stehen zur Verfügung. Die Form muß die Geometrie des
Kegelbaums und die Voraussetzung der Beschriftbarkeit berücksichtigen. Folgende
Konventionen werden diesen Anforderungen auf einfache Weise gerecht:
Die Form ist rechteckig. Die Höhe des Rechtecks ergibt
sich aus der Höhe der Beschriftung und oberem und unterem
Rand. Die Länge der Rechtecke wird so bemessen, daß
nur außergewöhnlich lange Begriffe oder Titel abgeschnitten
werden müssen. Da die Länge der Begriffe im
Durchschnitt kürzer ist als die der Dokumenttitel, sind die
Dokumentrechtecke länger.
68

Die Farbe der originalen Dokumentrechtecke ist Rot.
Die Farbe der Verweisdokumentrechtecke ist Hellrot. Ihre
Länge ist etwas verkürzt.
Die Farbe der originalen Begriffsrechtecke ist Blau.
Die Farbe der Verweisbegriffsrechtecke ist Hellblau. Ihre
Länge ist etwas verkürzt.
SOLAR ARCHITECTURE IN EUROPE
SOLAR ARCHITECTURE IN EUROPE
SOLAR
SOLAR
Abbildung: 3.8.
Knotenvisualisierung
4.1.5.2. Informationskodierung der Kegel
Im Kontextbaum folgt auf einen Knoten des einen Typs eine Gruppe von direkten
Nachfolgern, die alle dem jeweils anderen Typ von Knoten angehören. Die direkten
Nachfolger eines Begriffsknotens sind alle vom Typ ”Dokument”. Die direkten
Nachfolger eines Dokumentknotens sind alle vom Typ Begriff. Diese Teilbäume
heißen im folgenden Dokumentkegel, wenn der initiale Knoten vom Typ ”Dokument”
ist und Begriffskegel, wenn der initiale Knoten vom Typ ”Begriff” ist.
Ein Begriffskegel besteht aus dem initialen Begriff und einer Gruppe von Dokumentknoten,
die im folgenden Dokumentring heißt. Analog heißt die Begriffsgruppe
im Dokumentkegel Begriffsring. Kegel und Ringe sind in folgender Abbildung
anhand eines Teils des Beispielkontextbaum aus Abbildung 3.2. skizziert. Die Benennung
durch Kegel und Ring deutet bereits auf die Geometrie der Visualisierung
hin.
69

a
A B C
b c d e f g
Dokumentring
Begriffsring
Begriffskegel
Dokumentkegel
Abbildung: 3.9.
Kegel und Ringe
Die Visualisierung der Kegel enthält folgende Bestandteile:
Wurzelknoten
Ring der direkten Nachfolger
Hierarchiebeziehung zwischen Wurzel und Ring
Relevanzbeziehungen innerhalb des Rings
Die Visualisierung der Knoten wurde bereits festgelegt. Die Hierarchiebeziehung
wird gemäß dem Modell des Kegelbaums durch einen Konus dargestellt, an dessen
Spitze die Visualisierung des initialen Elements steht und an dessen Grundfläche die
Visualisierungen der Nachfolgerknoten angeordnet sind. Die Relevanzbeziehung
der Ringelemente wird durch Reihenfolge und Positionierung visualisiert. Folgende
Konventionen konkretisieren die Darstellung:
Die Spitze des Konus zeigt nach links. Die Höhe ist konstant,
der Umfang der Grundfläche ergibt sich aus dem
Platzbedarf des Rings. Die Mindestgröße der Grundfläche
entspricht einem Ring mit drei Elementen.
Die Farbe des Konus ist durchsichtiges Gelb. Objekte im
Hintergrund bleiben dadurch sichtbar.
Der Wurzelknoten steht direkt an der Kegelspitze.
Das Ringelement mit dem höchsten Relevanzwert berührt
mit seinem linken Rand den Umkreis der Konusgrundfläche.
Die folgenden Ringelemente schließen sich in
70

Reihenfolge ihrer Relevanz an und werden jeweils etwas in
Richtung Mitte der Grundfläche verschoben. Aus Sicht des
Betrachters liegen weniger relevante Ringelemente weiter
entfernt.
dritte Relevanz
zweite Relevanz
erste Relevanz
letzte Relevanz
Abbildung: 3.10.
Skizze eines Begriffskegels
Im linken Teil der Abbildung 3.10. wird die Geometrie eines Begriffskegels skizziert.
Im rechten Teil der Abbildung wird im Grundriß die relevanzabhängige Positionierung
der Dokumenttitel dargestellt. Der Aufbau eines Dokumentkegels ist
analog.
4.1.5.3. Spiralisierte Ringe
In Abbildung 3.10. sind alle Knotenbeschriftungen von außen lesbar, denn der Umfang
der Konus ist so gewählt, daß die Knoten nebeneinander Platz finden. Diese
Darstellung kann unübersichtlich werden, wenn ein Ring eine sehr große Anzahl
von Elementen beinhaltet, zum Beispiel weil ein besonders umfangreiches Dokument
der Datenbank in die Kontextmenge aufgenommen wurde. Eine mögliche
Strategie dem zu begegnen ist, eine maximale Anzahl von Ringelementen festzulegen.
Liefert eine Expansion mehr Elemente, so werden nur die relevantesten in den
Ring aufgenommen. Diese Strategie widerspricht jedoch der Zielsetzung der Inhaltsorientierung
und intuitiven Erfaßbarkeit des Suchdialogs, da organisatorische
Randbedingungen den Inhalt der Kontextmenge verfälschen.
Die spiralförmige Positionierung der Knoten auf der Konusgrundfläche erlaubt eine
Erweiterung der Kegelmetapher, die diese Problematik beseitigt. In zu großen Ringen
wird die Positionierungsspirale weiter fortgesetzt und dem Benutzer wird die
Möglichkeit gegeben, den Umfang eines Konus interaktiv zu variieren. Der Benutzer
kann so die Vordergrunddarstellung auf relevantere Information beschränken,
wird aber durch die teilweise verdeckten Elemente an deren Vorhandensein erinnert.
Für die Modellierung bietet sich die Archimedische Spirale [BRON, S. 94] an, auf
der alle benachbarten Schnittpunkte der Spirale mit einer Geraden aus dem Mittel-
71

punkt heraus den gleichen Abstand d voneinander haben. Die Länge des Spiralbogens
s vom Anfangspunkt A bis zum Mittelpunkt M berechnet sich durch:
s a( 2 1 arc sinh )
2
a v
Der Parameter a gibt das Verhältnis der Radiusveränderung v pro Winkelgeschwindigkeit
an. Der Wert a=(1/3)/(2 definiert eine Spirale, die sich nach einer Umkreisung
dem Mittelpunkt um 1/3 nähert. Der Winkel gibt an wieviele Umdrehungen
der Startpunkt vom Mittelpunkt enfernt ist.
Bei der Positionierung der Ringelemente auf einer Spirale reicht eine nährungsweise
Berechnung der Spirallänge aus. Die Formel für die Längenberechnung kann zu folgender
Nährungsformel vereinfacht werden.
s a2
2
Die Spirale in Abbildung 3.11. erreicht nach etwa 2,5 Umdrehungen den Punkt E.
Bei einer Fortsetzung bis zum Mittelpunkt M benötigte sie insgesamt etwa 3 Umdrehungen.
Die Gesamtlänge AM beträgt etwa 9 Radiuseinheiten. Nach Subtraktion des
Endstücks EM mit einer Länge von etwa 0,5 Radiuseinheiten ergibt sich eine Kurvenlänge
von etwa 8,5 Radiuseinheiten.
A
d
d
d
M
E
a v 1
3
2 0.05
3 2 18.8
AM : s 9
Konusumkreis
Abbildung: 3.11.
Spiralisierung
Der Benutzer soll die Länge der Außenwindung der Spirale interaktiv verändern
können, indem er kontinuierlich den Konusradius regelt. Die Spiralisierung muß
72

sich an den gewählten Konusradius anpassen. Die Bandbreite des Konusradius r
reicht von r max über r s bis r min.
r max : Der Umfang der Konusgrundfläche ist maximal.
Kein Ringelement ist verdeckt.
r s : Die Länge der Spirale ist gleich dem Platzbedarf des
Rings. Punkt E erreicht Mittelpunkt M.
r min : Der Umfang der Konusgrundfläche ist minimal. Als
minimale Größe wurde bereits der Umfang eines dreielementigen
Rings definiert.
Bei der r max- Darstellung ist der Innenbereich der Spirale frei. Bei abnehmendem r
wandern Ringelemente in den Innenbereich. Den Positionen der Elemente liegt zunächst
ein konstanter Spiralradiusveränderungswert v zugrunde. Wenn das innerste
Element den Mittelpunkt der Spirale erreicht, liegt der r s -Zustand vor. Bei einer weiteren
Radiusverringerung wird v variabel. Er muß jeweils so berechnet werden, daß
der Platzbedarf der Elemente und Spirallänge genau übereinstimmen.
Die vier Spiralen in Abbildung 3.12. verdeutlichen diesen Zusammenhang. Alle
Kurven sind gleich lang. Spirale A befindet sich im r max -Zustand. Für Spirale B wurde
r etwas verringert. In ihrem Innenbereich liegen bereits verdeckte Elemente. Spirale
C befindet sich im r s -Zustand. Die Kurve im Innenbereich hat den Mittelpunkt
erreicht. Bis zu diesem Zustand hat der Zwischenraum d zwischen den Windungen
konstante Breite. Bei einer weiteren Abnahme von r muß der Zwischenraum verkleinert
werden. In Spirale D ist r min erreicht.
73

d
d
r max
A
B
d
r s
r min
C
D
Abbildung: 3.12.
Spiralisierungsgrade
Für einen gegebenen Platzbedarf p eines Rings muß der Konusradius r für die möglichen
Werte innerhalb der Spiralisierungsbandbreite berechnet werden. Für den
r max -Zustand muß die Gesamtspirale so bemessen werden, daß die äußerste Windung
die Länge p hat, damit der Innenbereich frei bleibt. Ihre Gesamtdrehung bis
zum Mittelpunkt ist damit um 2 größer als die Drehung im Innenbereich i . p ist
gleich der Differenz aus der Länge der Gesamtspirale s und der Länge der freien Innenspirale
s i .
p s s i
p a( i 2)2
2
a 2
i
2
Auflösen nach i führt zum Drehwinkel der Innenspirale.
74

i
p
a(2 1)
Addition von 2 ergibt den Drehwinkel der Gesamtspirale. Division durch 2 liefert
die Gesamtzahl der Windungen. Multiplikation mit der Radiusveränderung pro Umdrehung
v führt zu r max, dem Maximalradius der Spirale und der Konusgrundfläche.
r max v i 2
2
Der zweite wichtige Eckwert ist der Radius r s . Die Gesamtlänge der Spirale vom
Anfangspunkt bis Mittelpunkt ist gleich dem Platzbedarf p des Rings. Nach s , dem
Drehwinkel dieser Spirale, wird aufgelöst.
p a s 2
2
s 2p
a
Division durch 2 liefert die Gesamtzahl der Windungen. Multiplikation mit der Radiusveränderung
pro Umdrehung v führt zu r s .
r s v s
2
Eine im Intervall [r max, r s ] liegende Benutzereingabe r kann iterativ zu Elementpositionen
für einen Ring mit n Elementen umgerechnet werden.
Pos(1) (r, 1 )
Pos(i) (r i1 v
2 , p(i)
i1 2 asin( ))
2r i1
1 i n
75

Die Positionsangaben sind in Polarkoordinaten definiert: Pos(i) = (Radius i , Winkel
i ). Die Position des ersten Elements kann durch den Startwinkel 1 gewählt werden.
Pos(3)
Pos(4)
r 4
r 5
1
5
r 2
Pos(2)
r
1
Pos(1)
Abbildung: 3.13.
Elementpositionen in Polarkoordinaten
Liegt der gewünschte Radius r im Intervall [r s, r min ], wird die volle Länge der Spirale
benötigt. Mit p ist die Länge festgelegt und mit s die Umdrehungen. Für die Anpassung
an r kann nur noch der Abstand der Windungen, der durch den Faktor a bestimmt
wird, herangezogen werden. Faktor a setzt sich aus Radiusveränderung v pro
Umdrehung 2 zusammen.
P a r 2 s
2
a r v r
2
Ersetzen von a und auflösen nach v ergibt:
76

v r 4p
2 s
Eine im Intervall [r s, r min ] liegende Benutzereingabe r kann iterativ zu Elementpositionen
für einen Ring mit n Elementen umgerechnet werden.
Pos(1) (r, 1 )
Pos(i) (r i1 v r
2 , p(i)
i1 2 asin( ))
2r i1
1 i n
Die Variationsbreite der Radiuswahl muß eingeschränkt werden, wenn Elemente
des Rings ihrerseits die Wurzel eines Unterbaums sind. Um Überlappungen von Unterringen
auszuschließen, darf der Radius nicht soweit verkleinert werden, daß diese
Elemente in den Innenbereich der Spirale wandern.
4.1.5.4. Animation und Interaktion mit dem Kontextbaum
Das Erscheinungsbild des Kontextbaums ist durch die Visualisierungsfestlegung für
Knoten und Kegel gegeben. Da die einzelnen Kegel von links nach rechts ausgerichtet
sind, ist auch der gesamte Kegelbaum von links nach rechts ausgerichtet. An der
Wurzel des Gesamtbaums befindet sich ein initialer Begriffs- oder Dokumentknoten.
Daran schließt sich der erste Dokument- oder Begriffskegel an. Der weitere
Aufbau des Kontextbaums ergibt sich aus dem Verlauf des Suchdialogs. In Abbildung
3.14. ist die Orientierung des Kontextbaums anhand eines Beispiels skizziert.
77

y
x
z
Abbildung: 3.14.
Orientierung des Kontextbaums
Zur Unterstützung des Benutzers bei der Entwicklung des Suchdialogs sind folgende
Animations- und Interaktionsfähigkeiten wichtig:
Gezielte Auswahl eines Knotens
Gezielte Auswahl eines Kegels
Vorwärts- und Rückwärtsbewegung innerhalb eines Rings
Vorwärts- und Rückwärtsbewegung innerhalb der Ebenen
des Baums
Transformation des Baums, so daß ein ausgewählter Knoten
und sein Kegel in den Vordergrund treten
Expansion eines ausgewählten Knotens
Löschen eines Teilbaums und seiner Unterbäume
Vergrößern und verkleinern des Bildausschnitts
Für die Benutzerinteraktion stehen folgende Werkzeuge zur Verfügung:
Tastatur
Maus
Spacemaus, Spaceball
78

virtuelle Schiebe- und Drehregler (Slider und Wheels)
virtuelle Knöpfe (Buttons)
Menüs
Die verschiedenen Werkzeuge zeichnen sich durch spezielle Interaktionsfähigkeiten
aus, denen Rechnung zu tragen ist. So ist die Maus besonders gut für eine absolute
direkte Anwahl eines Objektes durch Mausklick geeignet. Die Interaktion durch
Spaceball oder Spacemaus kann intuitiv gut einer relativen Bewegung eines bereits
selektierten Objekts zugeordnet werden. Slider, Wheels und Buttons sind auf dem
Rahmen des Darstellungsfensters angebracht und werden vom Benutzer intuitiv als
Werkzeuge zur Manipulation des gesamten Erscheinungsbildes begriffen. Die Tastatur
hat ihre Stärke in der Texteingabe und Menüs stellen Optionen bezüglich des
Zustandes des Gesamtsystems zur Auswahl. Die Bedienungsgewohnheiten verschiedener
Benutzer oder eines Benutzers vor und nach einer Lernphase mit dem System
können sich stark unterscheiden. Indem den Interaktionswerkzeugen Überschneidungen
in den zugeordneten Fähigkeiten erlaubt werden, ist es dem Benutzer
möglich, seine bevorzugte Arbeitsweise zu verfolgen. Im folgenden wird eine Zuordnung
von Aktion zu Werkzeu festgelegt:
Gezielte Auswahl eines Knotens:
– Auswahl durch Mausklick
Gezielte Auswahl eines Kegels:
– Auswahl durch Mausklick
Vorwärts– und Rückwärtsbewegung innerhalb eines Rings:
– Spaceball/Spacemaus Rotation um die x–Achse
(entspricht einer Drehung vorwärts oder rückwärts)
– Cursor aufwärts und abwärts
– Drehregler ’X–Rotation’
Vorwärts– und Rückwärtsbewegung innerhalb der Ebenen
des Baums:
– Spaceball/Spacemaus Translation entlang der x–Achse
(entspricht einer Bewegung nach links oder rechts)
– Cursortaste links und rechts
Transformation des Baums, so daß ein ausgewählter Knoten
und sein Kegel in den Vordergrund treten
– automatisch nach Wechsel des aktuellen Elements
Expansion eines ausgewählten Knotens:
– Spaceball/Spacemaus Pickbutton
– Cursortaste ’rechts’
– Menüeintrag ’Expand’
Löschen eines Teilbaums und seiner Unterbäume
– Taste ’Delete’
– Menüpunkt ’Delete’
79

Vergrößern und verkleinern des Bildausschnitts
– Schieberegler ’Distance’
Zu jedem Zeitpunkt ist ein Kegel des Baums und ein Element auf dem zum Kegel
gehörenden Ring aktuell ausgewählt. Der aktuelle Kegel und das aktuelle Element
werden durch eine auffällige, leuchtend grüne Farbgebung hervorgehoben. Alle Benutzerinteraktionen,
die eine Manipulation eines Elements oder Kegels zur Folge
haben, beziehen sich auf den aktuellen Kegel bzw. auf das aktuelle Element.
Nach einer Benutzerinteraktion, die einen Wechsel des aktuellen Kegels oder des aktuellen
Elements bewirkt, reagiert der gesamte Baum durch eine Animation, die den
aktuellen Kegel und das aktuelle Element in den Vordergrund bewegt.
4.1.5.4.1. Translation entlang der x–Achse
Die folgende Positionsangabe ’Bildmitte’ bezieht sich auf die Position des Wurzelknotens
des Baums. Diese befindet sich zu Beginn des Suchdialogs in der Bildschirmmitte,
kann aber durch den Benutzer verschoben werden. So ist sichergestellt,
daß eine Translation des gesamten Baums, zum Beispiel durch den Distanzregler,
durch die Animation nicht unwirksam wird. Ziel ist es, daß eine relative Bewegung
innerhalb des Baums auch eine gleichgroße Verschiebung des gesamten Baums zur
Folge hat.
Um die Ringelemente des aktuellen Kegels in die Bildmitte zu positionieren, muß
der Baum um die Höhe des aktuellen Kegels bezüglich der Wurzel nach links verschoben
werden. Zur Berechnung der Verschiebung dient wieder die Baumrepräsentation
in Listennotation. Der gesamte Baum ist als Liste L gegeben und a ist der Name
des aktuellen Knotens. Die Funktion XShift(L,a) berechnet den geforderten
Verschiebewert.
XShift(L, a) 0
XShift(L, a) 0
falls L
falls GetList(L)
Ein leerer Baum oder ein Baum, der nur aus einem Blatt besteht, wird nicht verschoben.
XShift(L, a) 0
XShift(L, a) XShift(tail(L), a)
falls GetName(head(L)) a
falls not(IsNodeOf (GetList(head(L)), a))
Ein Baum, an dessen Wurzel der gesuchte Knoten steht, muß ebenfalls nicht verschoben
werden, genausowenig ein Baum, der den gesuchten Knoten nicht enthält.
80

Das Prädikat IsNodeOf(B, k) untersucht, ob ein Knoten k im Baum B vorkommt. In
allen anderen Fällen ergibt sich der Verschiebewert aus der Summe der Höhe der Konen
zwischen Wurzel und gesuchtem Knoten.
XShift(L, a) ConeHeight(GetName(head(L))) XShift(GetList(head(L), a))
Da Dokument– und Begriffskonen unterschiedliche Höhen haben, ordnet die Funktion
ConeHeight(GetName(k)) einem Knoten k anhand seiner Knotenbeschreibung
GetName(k) eine zum Typ passende Konushöhe zu.
ConeHeight(b) DOCCONEHEIGHT
ConeHeight(b) WORDCONEHEIGHT
falls IsDocNode(b)
sonst
Das Prädikat IsDocNode(b) ist erfüllt, wenn es sich bei dem durch b beschriebenen
Knoten um einen Dokumentknoten handelt. Befindet sich b an der Wurzel eines Kegels
steht somit fest, daß es sich um einen Dokumentkegel handeln muß. Da nur zwei
unterschiedliche Knotentypen existieren, bedeutet die Nichterfüllung des Prädikats
das Vorliegen eines Begriffskegels. Die Höhe der beiden Kegeltypen ist konstant
und wird durch die Werte DOCCONEHEIGHT und WORDCONEHEIGHT definiert.
4.1.5.4.2. Translation entlang der z–Achse
Nachdem der Baum um das Ergebnis von XShift nach links verschoben wurde, ist
sichergestellt, daß sich der Ring, der das aktuelle Element beinhaltet, in der Bildschirmmitte
befindet. Darüber hinaus soll aber auch gewährleistet sein, daß die Entfernung
des aktuellen Knotens vom Betrachter sich nicht verändert. Der gesamte
Baum muß darum entsprechend nach vorne oder hinten geschoben werden, Bezugsgröße
ist wieder die Entfernung der Wurzel vom Betrachter. Die Funktion
ZShift(L,a) berechnet den geforderten Verschiebewert
ZShift(L, a) 0
ZShift(L, a) 0
falls L
falls GetList(L)
Ein leerer Baum, oder ein Baum der nur aus einem Blatt besteht, wird nicht verschoben.
81

ZShift(L, a) 0
falls GetName(head(L)) a
ZShift(L, a) ZShift(tail(L), a) falls not(IsNodeOf (GetList(head(L)), a))
Ein Baum, an dessen Wurzel der gesuchte Knoten steht, muß ebenfalls nicht verschoben
werden, genausowenig ein Baum, der den gesuchten Knoten nicht enthält.
In allen anderen Fällen ergibt sich der Verschiebewert aus der Summe der Radien
der Konen zwischen Wurzel und gesuchtem Knoten.
ZShift(L, a) ConeRadius(head(L)) ZShift(GetList(tail(L), a))
Die Funktion ConeRadius(k) liefert zu einem Knoten k den Radius der folgenden
Konusgrundfläche. Auf die Berechnung des Konusradius wurde im Abschnitt
4.1.5.3. ausführlich eingegangen.
4.1.5.4.3. Rotation der Kegel
Nachdem die absolute Position des Baums bestimmt ist, bleibt nun noch zu definieren,
wie die Kegel des Baums rotiert werden müssen, so daß das aktuelle Element
mit Front zum Benutzer ausgerichtet ist.
In der folgenden Spezifikation wird davon ausgegangen, daß ein um den Winkel i
rotierter Kegel sein i–tes Ringelement im Bildschirmvordergrund zeigt. Wir können
darum auf die im Abschnitt 4.1.5.3. eingeführten Polarkoordinaten für die Elementpositionen
zurückgreifen. Ein Kegel, gegeben durch seinen Wurzelknoten k, muß
nur dann rotiert werden, wenn das aktuelle Element a zu seinen Nachfolgerknoten
gehört. Die Definition des Funktionswerts NONE bedeutet, daß der Rotationswert
des Kegels nicht geändert wird, damit der Benutzer nicht durch unnötige Baumtransformationen
abgelenkt wird.
Rotation(k, a) NONE
Rotation(k, a) NONE
falls GetList(k)
falls not(IsNodeOf (GetList(k), a))
Gehört a aber zu den Nachfolgern von k, muß der Index des Ringelements bestimmt
werden, das mit a identisch ist oder a als Nachfolger hat. Die Hilfsfunktion Index(Liste,
Knoten) liefert den gewünschten Wert.
82

Index(L, a) 1 falls head(L) a IsNodeOf (GetList(L), a)
Index(L, a) 1 Index(tail(L), a) sonst
Eine weitere Hilfsfunktion Angle(L, i) liefere den Winkel des i–ten Listenelements.
Rotation(k, a) Rotation(Angle(Index(GetList(k), a)))
83

Blick
richtung
b
r 2 a
k
2
2
3
k 3 r 3
1
r 1
w k 1
Blick
richtung
r 3
r 2
r 1
a k 3 k 2
w k 1
Abbildung: 3.15.
Kegelrotation
In Abbildung 3.15. ist ein Kegelbaum schematisch im Grundriß in zwei Zuständen
skizziert. Im oberen Zustand ist Knoten b im Kegel unter dem Wurzelknoten w das
aktuelle Element. Der Benutzer selektiert Knoten a als neues aktuelles Element. Auf
dem Pfad von w nach a liegen die Knoten k 2 und k 3 . Die Kegel unter w 1 , k 2 und k 3
werden um die Winkel , und rotiert. Der gesamte Baum wurde außerdem
84

um r 2 +r 3 vom Betrachter wegbewegt, um a im gewohnten Abstand zu positionieren.
Im unteren Teil der Abbildung hat der Kegelbaum seinen Zielzustand erreicht.
85

4.2. Präsentation der Ergebnismenge
In diesem Kapitel wird das Modell des zweiten Interaktionswerkzeugs der Benutzerschnittstelle
vorgestellt.
Durch den Suchpfad im ’Kontextbaum’ hat der Benutzer intuitiv eine Anfrage an
den automatischen Retrieval-Mechanismus formuliert, welche aus einer Menge von
Termen der Datenbank besteht. Die Terme werden in der Anfrage implizit ODERverknüpft.
Mit der Metapher der ’Relevanzkugel’ leistet das System nun eine Zusammenfassung
und Darstellung der Ergebnismenge.
4.2.1. Präsentation in traditionellen Retrieval Systemen
In herkömmlichen, bibliographischen Retrievalsystemen wird dem Benutzer die Ergebnismenge
in Form einer sequentiellen Liste von Dokumententiteln präsentiert.
Insbesondere bei sehr großen Datenbanken tritt schnell das Problem auf, daß nur
noch ein kleiner Teil der Dokumente der Ergebnismenge dargestellt werden kann.
Um die gesamte Menge darstellen zu können, muß die Präsentation in mehrere
(Bildschirm–)Seiten unterteilt werden. Der Benutzer verliert so schnell den Überblick
über die Ergebnismenge.
Um die Größe der Ergebnismenge zu beschränken, treffen viele Retrievalsysteme
eine Auswahl von besonders relevanten Dokumenten, ohne daß die individuelle
Suchsituation des Benutzers berücksichtigt wird.
Die Entscheidung über den Relevanzwert eines Dokuments trifft nur das System und
nicht der Benutzer. Durch dieses Verfahren wird dem Benutzer Information vorenthalten.
Er erfährt nichts über Dokumente, welche vom System als ungenügend relevant
beurteilt wurden.
Eine Darstellung der ausgewählten Dokumentenmenge als sequentielle Liste, wie
man sie von herkömmlichen Retrievalsystemen gewohnt ist, vermittelt dem Benutzer
keine zusätzliche Information über die ausgewählten Dokumente. Die Auswahlkriterien
des Systems bleiben dem Benutzer verborgen. Bestenfalls kann die Reihenfolge,
in welcher die Dokumente in der Liste angeordnet sind, einen schwachen
Anhaltspunkt über das Relevanzmaß bestimmter Dokumente liefern.
Desweiteren kann eine Listendarstellung keine Information über semantische Beziehungen
zwischen einzelnen Dokumenten liefern. Der Benutzer erhält durch die
Listendarstellung der Ergebnismenge auch keine weitere Hilfe zur Verbesserung der
Anfrage.
Ziel einer besseren Repräsentation muß es sein, die Auswahl bestimmter Dokumentengruppen
aus der Ergebnismenge dem Benutzer zu überlassen. Das System sollte
86

weniger die Auswahl bestimmter Dokumentengruppen, als vielmehr die Darstellung
einer möglichst vollständigen Ergebnismenge leisten. R.R. Korfhage formuliert
dies in seiner Forderung: ”The Viewpoint should shift from retrieval to display”
[KORF91].
Um dem Benutzer mehr Information über die von ihm gewünschte Dokumentenmenge
zu vermitteln, muß die Listendarstellung durch eine geeignete graphische
Darstellung ersetzt werden. Es kann ihm so Information durch graphische Gegebenheiten,
die er intuitiv erfaßt, vermittelt werden.
Verschiedene graphische Modelle zur Darstellung der Ergebnisse einer Retrievalanforderung
sind denkbar.
4.2.2. Beispiele graphischer Präsentation
Die zwei folgenden Beispiele einer graphischen Ergebnisrepräsentation basieren
auf dem unter Kapitel 3.6.1.1. vorgestellten Inhaltsnetz vektorbasierter Information
Retrieval Systeme. Der Inhalt der Datenbasis wird durch ein spezielles Inferenznetz
repräsentiert. Der Inhalt content eines Textdokuments wird im Vektormodell durch
den in Kapitel 3.6.1.1. beschriebenen Inhaltsvektor dargestellt:
content(d) (w 1d , w 2d , w 3d , ... , w md )
((content(w 1d ), g(w 1 , d)), ... , (content(w md ), g(w m , d)))
D
Mit den Begriffen der Anfrage an das Retrieval System werden sogenannte Referenzpunkte
definiert. Das Vektormodell wird nun auf ein Abstandsmodell zur graphischen
Repräsentation angewendet. Die Gewichtung der Referenzpunkte und somit
der Begriffe bezüglich der verschiedenen Dokumente wird durch eine Funktion
transform auf Abstände in der graphischen Darstellung abgebildet:
distance(w, d) transform(content(d), content(w))
Beispiele für verschiedene Definitionen der Abstandsfunktion distance finden sich
in Kapitel 4.2.3.1..
Der semantische Abstand zwischen Dokument und Begriff wird zum Beispiel auf
den geometrischen Abstand der jeweiligen Symbole in der Darstellung abgebildet.
Der semantische Verwandtschaftsgrad von verschiedenen Dokumenten läßt sich am
Abstand ihrer Symbole in der Darstellung ablesen.
87

Abstand muß nicht in jedem Fall der geometrische Abstand sein. Es sind viele Abbildungen
auf die verschiedenen Parameter einer graphischen Darstellung denkbar,
wie zum Beispiel eine Abbildung auf die Farbwerte der Darstellung und einem damit
definierten ’Farbabstand’ zwischen den Symbolen.
4.2.2.1. Das GUIDO–System
Das GUIDO–System (Graphical User Interface for Data Organisation) [KORF91]
basiert auf dem oben beschriebenen Abstandsmodell.
Durch n einzelne Worte oder Wortgruppen werden Referenzpunkte definiert, welche
einen n–dimensionalen Raum aufspannen. Die Referenzpunkte werden nicht
durch Punkte des Raumes, sondern durch die Koordinatenachsen dargestellt. Die
Dokumentensymbole der Ergebnismenge werden als Punkte dieses Raumes repräsentiert,
deren Koordinaten sich aus der Relevanz bezüglich der einzelnen Referenzpunkte
berechnet.
B
Für diese Dokument ist nur
Referenzpunkt B relevant
Für dieses Dokument sind beide Referenzpunkte
sehr relevant
Für diese Gruppe von Dokumenten ist Punkt A
sehr relevant und Punkt B ein wenig
A
Darstellungen des GUIDO–Systems mit zwei Referenz-
Abbildung: 3.16.
punkten
Eine solche Darstellung vermittelt dem Benutzer neue Informationen, ohne daß er
sich zur näheren Auswahl einer bestimmten Dokumentengruppe mit dem Inhalt der
Dokumente vertraut machen muß. Er sieht anhand der Position eines jeden Dokuments,
welche Schlüsselworte verantwortlich für die Aufnahme in die Ergebnismenge
waren. Auch Beziehungen, d.h. semantische Abstände zwischen verschiedenen
Dokumenten lassen sich durch ihre Position erkennen.
Dokumente, die räumlich eine Gruppe bilden, bilden auch thematisch eine Gruppe,
da sie ähnliche Relevanzwerte bezüglich der verschiedenen Referenzpunkte haben.
Für den Fall, daß der Benutzer nur drei oder weniger Referenzpunkte definiert, läßt
sich die Darstellung mit gewöhnlichen graphischen Techniken handhaben. Weitere
88

Referenzpunkte bzw. Dimensionen müssen durch andere graphische Attribute wie
Farbe, Form, Größe oder Bewegung simuliert werden.
Es ist fraglich, inwieweit der Benutzer in der Lage ist, bei einer solchen mehrdimensionalen
Darstellung die graphischen Gegebenheiten der Darstellung intuitiv zu erfassen,
da zur Abbildung der Relevanzwerte eine Abstandsfunktion für Attribute
wie Form oder Bewegung der Symbole definiert werden muß.
Das GUIDO–System eignet sich deshalb nur zur Darstellung von Ergebnismengen
mit einer kleinen Menge von Referenzpunkten.
4.2.2.2. Das VIBE–System
Das VIBE–System (Visualisation By Example) [OLSEN91] ist eine graphische
Darstellung der Ergebnismenge in der Ebene.
Mit den Begriffen der Retrievalanfrage werden Referenzpunkte als geometrische
Punkte in der Ebene definiert, die die Ecken eines Polygons bilden. Die Dokumente
der Ergebnismenge werden durch graphische Symbole im Inneren des Polygons
dargestellt.
Die Position der einzelnen Dokumente berechnet sich anhand der Relevanzwerte bezüglich
der einzelnen Referenzpunkte. Je relevanter ein Referenzpunkt für ein bestimmtes
Dokument ist, desto näher wird das Dokument positioniert. Der semantische
Abstand zwischen zwei Dokumenten wird so direkt auf den geometrischen
Abstand zwischen den betreffenden Symbolen abgebildet.
Durch die Beschränkung auf eine zweidimensionale Darstellung entsprechen die
geometrischen Abstände der Dokumente von den Referenzpunkten nicht mehr absoluten
Relevanzwerten, sondern vielmehr dem Verhältnis des Dokumentes zu allen
Referenzpunkten der Darstellung. Es geht somit ein Teil der Information verloren,
wie der Darstellung in Abbildung 3.17. zu entnehmen ist.
Für das Dokumentensymbol, welches genau in der Mitte des von den Referenzpunkten
A, B, C und E aufgespannten Vierecks liegt, ist hier nicht klar entscheidbar, welcher
der vier Referenzpunkte besonders relevant für das betreffende Dokument ist.
89

B
C
In der Mitte zwischen C und D
bedeutet gleicher Einfluß der
Punkte C und D
Alle Dokumente im von A,B und C
aufgespannten Dreieck werden
auch von B beeinflußt
D
Dieses Dokument kann aus
verschiedenen Gründen
hier positioniert sein
Starker Einfluß von A
und schwacher Einfluß von E
A
E
Abbildung: 3.17.
Ergebnispräsentation mit dem VIBE-System [KORF91]
Dem Verlust an Information steht eine leichter handhabbare Darstellung gegenüber.
Der Benutzer kann auch bei einer größeren Anzahl von Referenzpunkten die graphischen
Gegebenheiten intuitiv erfassen.
4.2.3. Präsentation durch die Relevanzkugel
Das Präsentationsmodell der ’Relevanzkugel’ ist eine Erweiterung der zweidimensionalen
Darstellung des VIBE–Systems auf eine dreidimensionale Darstellung im
Raum. An die Stelle des durch die Referenzpunkte aufgespannten Polygons tritt eine
transparente Kugel, auf deren Oberfläche die Symbole der Referenzpunkte gleichmäßig
verteilt dargestellt werden.
Die Referenzpunkte werden durch die einzelnen Schlüsselworte des Suchpfades des
in Kapitel 4.1. beschriebenen Kontextbaum definiert. Die Dokumente der Ergebnismenge
werden im Inneren der Kugel dargestellt. Sie werden entsprechend ihrer Relevanzwerte
von den Schlüsselworten aus dem Kugelzentrum herausgezogen.
Wie bei der Polygondarstellung des VIBE–Systems entsprechen die Abstände der
Dokumente von den einzelnen Referenzpunkten nicht den absoluten Relevanzwer-
90

ten, sondern dem Verhältnis des Dokumentes zu allen Referenzpunkten. Auch in der
Kugeldarstellung können deshalb Dokumente aus verschiedenen Gründen an derselben
Position im Raum liegen.
Durch den zusätzlichen Freiheitsgrad der dreidimensionalen Darstellung ist jedoch
die Wahrscheinlichkeit eines Informationsverlustes durch eine solche Positionsüberlappung
geringer als bei der Darstellung in der Ebene.
Während bei der 2D–Darstellung vom Benutzer etwa 12 tortenstückartige Segmente
unterschieden werden können, bietet die Kugel bei gleichem Radius und gleichem
Öffnungswinkel der Segmente die etwa doppelte Anzahl (Abbildung 3.18.). Es ist
bei der Kugeldarstellung also potentiell leichter, Dokumente zu verschiedenen Dokumentengruppen
(Clustern) zuzuordnen.
r
a. Unterteilung in 12 Segmente (2D) b. Unterteilung in 20 Segmente (3D)
Abbildung: 3.18.
Intuitive Segmentierung durch den Benutzer
Die dreidimensionale Kugeldarstellung bietet außerdem mehr Positionierungsmöglichkeiten
für die Referenzpunkte. Ein konkreter Vergleich der möglichen Positionsanzahlen
läßt sich anhand der folgenden Berechnungen durchführen:
1. Bei einer minimalen Distanz e zwischen zwei Referenzpunkten
auf dem Rand des Kreises mit Radius r in der
zweidimensionalen Darstellung läßt sich die Anzahl der
möglichen Positionen auf dem Rand wie folgt berechnen:
RefPosAnzahl2D(r, e) 2r
e
2. Bei einer minimalen Distanz e zwischen zwei Referenzpunkten
auf der Oberfläche der Kugel mit Radius r in der
dreidimensionalen Darstellung läßt sich die Anzahl der
möglichen Positionen auf der Oberfläche durch folgende
Funktion berechnen:
91

RefPosAnzahl3D(r, e) 4r2
e 2 4r2
e 2
Das Verhältnis der Anzahlen der beiden Darstellungen erhält man somit als Quotient
der beiden Funktionen:
4r
RefPosAnzahl3D(r, d)
2
RefPosAnzahl2D(r, d) e 2
2r
e
2r
e
Folglich bietet die Kugeldarstellung bei gleichem Radius r um einen Faktor 2r/e
mehr Möglichkeiten die Referenzpunkte zu positionieren.
4r 2 2r
Kugeldarstellung (3D)
Kreisdarstellung (2D)
r
Abbildung: 3.19. Anzahlen möglicher Referenzpunktpositionen (mit e = 1)
Ähnlich lassen sich die Anzahlen der möglichen Positionen der Dokumentensymbole
in Kreis- und Kugeldarstellung vergleichen:
1. Bei einer minimalen Ausdehnung d einer Dokumentenpositionen
im Inneren des Kreises mit Radius r läßt sich
die Anzahl der möglichen Positionen in der zweidimensionalen
Darstellung wie folgt berechnen:
DocPosAnzahl2D(r, d) r2
d 2 r2
d 2
2. In der dreidimensionalen Darstellung läßt sich die Anzahl
der möglichen Dokumentpositionen bei einer minimalen
Positionsausdehnung d im Inneren einer Kugel mit Radius
r durch die folgende Funktion DocPosAnzahl3D(r,d)
berechnen:
92

DocPosAnzahl3D(r, d)
4
3 r3 r3
4
3
d3 d 3
Mit den beiden Funktionen läßt sich das Verhältnis zwischen den Anzahlen der möglichen
Dokumentenpositionen berechnen:
r 3
DocPosAnzahl3D(r, d)
DocPosAnzahl2D(r, d) d 3
r r 2 d
d 2
Die Kugeldarstellung bietet bei gleichem Radius r um einen Faktor r/d mehr Möglichkeiten,
die Dokumentensymbole zu positionieren. Es ist somit unwahrscheinlicher,
daß Dokumente, die thematisch nicht miteinander verwandt sind, räumlich nahe
zueinander positioniert werden.
Dieser Effekt wird in Abbildung 3.20. an einem Präsentationsbeispiel mit vier Relevanzpunkten
verdeutlicht.
In der zweidimensionalen Darstellung des VIBE–Systems werden die Dokumente
a, b und c, obwohl sie völlig unterschiedliche Relevanzwerte bezüglich der vier Referenzpunkte
haben, an der gleichen Position dargestellt. In der dreidimensionalen
Darstellung hingegen läßt sich die thematische Unabhängigkeit dieser drei Dokumente
leicht ablesen.
Um den verbleibenden Informationsverlust zu kompensieren, ist es sinnvoll dem
Benutzer, Interaktionsmöglichkeiten zur Verfügung zu stellen. Er kann sich so durch
Manipulation der Darstellung Klarheit darüber verschaffen, welche Referenzpunkte
für die Position bestimmter Dokumente verantwortlich sind.
93

A
B
d
a
c
b
D
e
C
VIBE–System (2D)
A
d
a
D
c
b
B
Relevanzkugel (3D)
Relevanzwerte der einzelnen Dokumente der Darstellung:
Für Dokument a sind nur die Referenzpunkte A und C etwa gleich relevant
Für Dokument b sind alle Referenzpunkte in gleichem Maße relevant
Für Dokument c sind nur die Referenzpunkte B und D etwa gleich relevant
Für Dokument d sind nur die Referenzpunkte A und D etwa gleich relevant
Für Dokument e ist Referenzpunkt C sehr und Punkt D ein wenig relevant
e
C
Abbildung: 3.20.
Darstellungen des VIBE–Systems und der Relevanzkugel
94

4.2.3.1. Positionierung der Dokumente
Entscheidend für den Wert einer graphischen Darstellung der Ergebnismenge ist die
Güte der Abbildung der Relevanzwerte auf die geometrischen Parameter der Darstellung,
im Fall der Relevanzkugel, die Abbildung auf die Abstandswerte im Raum.
Der Benutzer soll anhand der Position der Dokumentensymbole eine möglichst genaue
thematische Zuordnung des zugehörigen Dokuments durchführen können.
Die Berechnung geeigneter Abstandswerte geschieht anhand der Topologie des in
Kapitel 3.6.1.1. beschriebenen Inhaltsnetzes. Der Inhalt der Dokumente wird durch
den Vektor content(d) beschrieben. Anhand der im Dokumentenvektor enthaltenen
Begriffsgewichte läßt sich die absolute Häufigkeit der verschiedenen Begriffe in
dem betreffenden Dokument ermitteln.
Eine direkte Abbildung der jeweiligen absoluten Häufigkeiten auf die Abstandswerte
ist jedoch wenig sinnvoll, da die Schlüsselworte eines besonders kleinen Dokuments
für dieses bei gleicher Häufigkeit sehr viel relevanter sind als die eines besonders
großen. Außerdem liefert die Abstandseinteilung nach den absoluten
Worthäufigkeiten nur eine sehr grobe Positionsauflösung im Raum.
Die Abstandswerte müssen relativ zum Inhalt der jeweiligen Dokumente berechnet
werden. Eine Möglichkeit besteht darin, die Werte abhängig von der Gesamthäufigkeit
der Begriffe der Retrievalanfrage (der Query) zu berechnen. Mit Hilfe der unter
Kapitel 3.6.1.1. definierten Funktion count(w,d) zur Berechnung der absoluten Häufigkeit
des Begriffs w im Dokument d, läßt sich so eine Funktion zur Berechnung
des Abstandes zwischen den Symbolen von d und w definieren (Auf die Skalierungsfunktion
scaling wird im folgenden genauer eingegangen):
distance 1 (w, d)
i: w i Query
count(w, d)
count(w i , d) scaling
Insbesondere bei einer kleinen Anzahl von Begriffen in der Retrievalanfrage tritt bei
einer Abstandsberechnung mit der Funktion distance 1 das Problem einer zu groben
Positionsauflösung auf. Der Vorteil der großen Menge an Positionen im Raum wird
nicht genutzt.
Eine höhere Auflösung wird zum Beispiel durch eine Berechnung des Abstandes relativ
zur Summe der absoluten Häufigkeiten aller Schlüsselworte der Datenbank im
Dokument d, erreicht.
95

distance 2 (w, d)
i: w i Database
count(w, d)
count(w i , d) scaling
Eine noch höhere Positionsauflösung liefert die Berechnung der Abstandswerte relativ
zur jeweiligen Dokumentenlänge. Die Dokumentenlänge kann mit Hilfe der
unter Kapitel 3.6.1.1. definierten Funktion len(d) berechnet werden.
distance 3 (w, d)
count(w, d)
len(d)
scaling
Das Skalieren der Werte erfolgt jeweils durch eine geeignete scaling Funktion, für
distance 3 beispielsweise durch die im folgenden definierte Funktion. Mit scaling 3
wird der größte Abstandswert der aktuellen Darstellung unter Berücksichtigung aller
Begriffe der Anfrage und aller als Ergebnis erhaltenen Dokumente berechnet.
scaling 3
max
i,j: d i retrieved Docs w j Query
len(d i )
count(w j , d i )
In der graphischen Darstellung entspricht der Wert der distance Funktion der Länge
des Vektors, der das Dokumentensymbol in Richtung des betreffenden Referenzpunktes
aus dem Kugelmittelpunkt herauszieht.
Der Positionsvektor eines Dokumentensymbols errechnet sich aus der Addition der
einzelnen Vektoren bezüglich aller Referenzpunkte der Darstellung. Abbildung
3.21. zeigt die Positionsvektoren von vier Referenzpunkten (A, B, C und D) bezüglich
eines Dokuments. In Abbildung 3.22.werden die vier Vektoren zu einem
Positionsvektor, der die Dokumentposition beschreibt, addiert.
96

B
A
C
doc
distance 3 (doc, A)
distance 3 (doc, B)
D
distance 3 (doc, C)
distance 3 (doc, D)
Abbildung: 3.21.
Vektoren der Referenzpunktanziehungskräfte
B
A
doc
C
D
Abbildung: 3.22.
Positionierung des Dokumentensymbols
Welche der verschiedenen aufgeführten Funktionen die beste Dokumentenpositionierung
zur Folge hat, hängt von den individuellen Gegebenheiten der verwendeten
Datenbank ab. Aus diesem Grund sollte es dem Benutzer möglich sein, die Wahl der
verwendeten Abbildung interaktiv zu treffen.
4.2.3.2. Positionierung der Wortsymbole
Entscheidend für eine aussagekräftige Positionierung der Dokumentensymbole im
Inneren der Relevanzkugel ist auch die Anordnung der Referenzpunkte, d.h. der
97

Wortsymbole der Worte aus der Query auf der Oberfläche der Kugel. Durch diese
Anordnung wird das Innere der Kugel in Themensegmente aufgeteilt, deren Eckpunkte
auf der Kugeloberfläche durch die Referenzpunkte definiert sind. Wie Abbildung
3.23. zeigt, befinden sich in einem Themensegment jeweils die Dokumente,
für die die segmentbildenden Referenzpunkte relevant sind.
E
A
D
B
Für die Dokumente deren Symbole
sich im Inneren des dunkler dargestellten
Segments befinden, sind die
Referenzpunkte A,B und C relevant.
C
F
Abbildung: 3.23.
Darstellung eines Themensegments in der Relevanzkugel
Bei der initialen Positionierung durch das System sollten die Abstände zwischen den
einzelnen Referenzpunkten möglichst gleich sein, um möglichst gleiche Volumen
der Themensegmente im Inneren der Kugel zu erhalten.
Denkbar ist es natürlich auch, eine initiale Positionierung abhängig von Beziehungen
zwischen einzelnen Referenzpunkten durchzuführen. Dies bedeutet, daß das
System Referenzpunkte, die es als ähnlich oder semantisch verwandt beurteilt, nahe
zueinander positioniert.
Das Problem einer solchen Vorgehensweise ist, daß das System eine Ähnlichkeitsbeurteilung
durchführt, ohne die individuelle Suchsituation des Benutzers zu berücksichtigen.
So können Worte und somit Referenzpunkte in verschiedenen Zusammenhängen
auch unterschiedlich stark semantisch verwandt sein.
Ausgehend von einer Gleichverteilung der Referenzpunkte auf der Kugeloberfläche
sollte es dem Benutzer überlassen sein, die Referenzpunkte nach seinen individuellen
Anforderungen umzusortieren.
Bei einer Gleichverteilung spannen die Referenzpunkte einen regulären Polyeder
auf (Abbildung 3.24. ). Reguläre Polyeder werden von kongruenten regulären Polygonen
begrenzt. Die in einer Ecke zusammenlaufenden Kanten bilden kongruente
Eckenfiguren. Da ein n–Eck in (n–2) Dreiecke zerlegt werden kann, beträgt die Größe
eines Innenwinkels im regulären n–Eck ((n–2)·180/n). An jeder Ecke eines Po-
98

lyeders stoßen mindestens drei Flächen zusammen. Da die Summe der an einer Ecke
liegenden Winkel aber kleiner als 360
Da es damit nur fünf reguläre, konvexe Polyeder gibt, ist eine Gleichverteilung nur
bei fünf verschiedenen Kardinalitäten der Referenzpunktmenge möglich.
a. Tetraeder (4 Ecken)
c. Würfel (8 Ecken)
e. Dodekaeder (20 Ecken)
b. Oktaeder (6 Ecken)
d. Ikosaeder (12 Ecken)
Abbildung: 3.24.
Die platonischen Polyeder
Für Referenzpunktmengen anderer Kardinalität muß eine annähernde Gleichverteilung
genügen.
Realisiert werden kann die Verteilung der Referenzpunkte durch eine Tabelle, in der
für jede sinnvolle Anzahl von Referenzpunkten und für jeden einzelnen Punkt die
initiale Position eingetragen ist. Ein Eintrag beschreibt eine Position auf der Kugel
durch zwei Winkelangaben für Rotationen um zwei der drei Achsen. So kann ausgehend
vom höchsten Punkt der Kugel jede Position auf der Kugeloberfläche beschrieben
werden.
4.2.3.3. Interaktionsmöglichkeiten des Benutzers
Die Darstellung der Relevanzkugel soll dem Benutzer ermöglichen die Dokumente,
die das Retrievalsystem als Ergebnis auf seine Anfrage geliefert hat und welche im
Inneren der Kugel dargestellt werden, nach ihrer thematischen Zusammengehörigkeit
zu ordnen. Wie bereits oben erwähnt, soll diese Ordnung nicht nach den allgemeinen
Kriterien des Systems, sondern nach den speziellen Anforderungen des Benutzers
erfolgen.
Dem Benutzer müssen also verschiedene Interaktionsmöglichkeiten zur Verfügung
gestellt werden, mit denen er die Darstellung der Relevanzkugel beeinflussen und
die Dokumentensymbole gruppieren (clustern) kann.
99

4.2.3.3.1. Positionierung der Referenzpunkte
Als erstes muß es dem Benutzer möglich sein, die Position der Referenzpunkte auf
der Kugeloberfläche zu ändern. Er kann Referenzpunkte, die ihm für seine Suchsituation
besonders relevant erscheinen, so positionieren, daß sie ein Themensegment
bilden. Für alle Dokumente deren Symbole sich im Inneren des so gebildeten Segmentes
befinden, sind dann die vom Benutzer ausgewählten Referenzpunkte relevant.
Abbildung 3.25. zeigt ein Themensegment, das durch die Schlüsselworte house,
energy und solar gebildet wird. Alle im Inneren des Segments dargestellten Dokumentensymbole
werden mindestens von einem der drei Referenzpunkte angezogen.
Die drei Schlüsselworte sind für die durch die Symbole repräsentierten Dokumente
relevant.
house
h
g
f
e
d
a
b
c
energy
solar
Abbildung: 3.25.
Themensegment in der Relevanzkugel
Das Verständnis für die semantischen Zusammenhänge der einzelnen Symbole kann
durch eine direkte Reaktion der Dokumentensymbole auf Positionsveränderungen
der Referenzpunkte verstärkt werden. Wenn ein bestimmter Referenzpunkt bewegt
wird, so folgen ihm alle Dokumentensymbole von Dokumenten, für die er relevant
ist.
Als Eingabemedium für die Rotationsbewegung der Symbole auf der Kugeloberfläche
eignet sich besonders der Spaceball, da er dem Benutzer ein intuitives Verständnis
für die Bewegung vermittelt [s. Kapitel 2.3.2.2.]. Eine Bewegung der Symbole
auf der Kugeloberfläche läßt sich jedoch auch mit einer ’normalen’ Maus als Eingabemedium
realisieren[s. Kapitel 2.3.2.1.]. Da durch Rotationen um zwei der drei
Achsen jede Position auf der Oberfläche der Kugel erreicht werden kann, reicht es
aus, die vier Richtungen der Mausbewegung in der Ebene auf vier Rotationsrichtungen
um die Kugel abzubilden.
100

y
y
x
z
x
Abbildung: 3.26.
Abbildung der Mausbewegung
4.2.3.3.2. Manipulation der Relevanzwerte
Da die verschiedenen Referenzpunkte unterschiedlich relevant in der speziellen
Suchsituation des Benutzers sein können, muß es dem Benutzer möglich sein, den
Punkten verschiedene Interessengewichte zuzuordnen und diese interaktiv zu verändern.
Eine solche Interessengewichtsveränderung und die damit verbundene Veränderung
der Anziehungskraft der Symbole läßt sich durch eine Modifikation der im Abschnitt
4.2.3.1. definierten Funktion zur Berechnung des Abstandswerts zwischen
einem Dokument und einem Referenzpunkt realisieren. Durch die Einführung der
Variablen relevanz(w) läßt sich der Wert der durch count berechneten absoluten
Häufigkeit eines bestimmten Begriffs verändern.
distance 3 (w, d)
count(w, d) relevanz(w)
len(d)
scaling
Es sind verschiedene Möglichkeiten denkbar, das Interessengewicht eines Referenzpunktes
zu visualisieren. So wird beispielsweise in der zweidimensionalen Darstellung
des VIBE–Systems die Position der Referenzpunkte nach aussen gezogen, um
eine stärkere Gewichtung zu visualisieren. Dies hat zur Folge, daß die Referenzpunkte
nicht mehr auf einem Kreis liegen. In der dreidimensionalen Darstellung ist
diese Vorgehensweise problematisch, da die Darstellung durch ein Überschreiten
der Kugelgrenzen für den Benutzer schnell schwerer erfaßbar wird.
101

In der Relevanzkugeldarstellung ist es besser, die Größe der Referenzpunktsymbole
proportional zu dem jeweiligen Gewichtswert zu ändern. Diese Art der Visualisierung
unterstützt gleichzeitig das Verständnis des Benutzers für die Metapher der Anziehungskraft,
die die Referenzpunkte auf die Dokumentensymbole ausüben. Er
kann die Anziehungskraft intuitiv als Gravitationskraft der Symbole verstehen.
Abbildung 3.27. zeigt das Themensegment aus Abbildung 3.25. nach einer Verstärkung
des Relevanzwertes des Referenzpunktes, der durch das Schlüsselwort solar
definiert wird. Man erkennt, daß der Begriff solar besonders für die Dokumente, deren
Symbole mit c,d und g gekennzeichnet sind, relevant ist.
house
h
f
e
a
b
g
d
c
energy
solar
Abbildung: 3.27.
Veränderung des Relevanzwertes eines Referenzpunktes
Der Nachteil einer Abbildung der Interessengewichte auf die Symbolgröße ist, daß
es bei einer dreidimensionalen Darstellung auf einem gewöhnlichen zweidimensionalen
Ausgabegerät zu Mißverständnissen kommen kann, wenn für den Benutzer
nicht klar ersichtlich ist, ob eine bestimmte Symbolgröße auf das Interessengewicht
oder auf die Position im Raum zurückzuführen ist. Bei einer richtigen dreidimensionalen
Darstellung, die zum Beispiel durch den Einsatz von 3D-Brillen erreicht werden
kann, kann der Benutzer die graphischen Attribute Entfernung und Symbolgröße
klar unterscheiden.
Dieses Problem läßt sich umgehen, indem die Visualisierung der Interessengewichte
durch eine Farbhelligkeits- oder Farbartcodierung realisiert wird, d.h., wenn der
Helligkeits- oder Farbartwert der Symbole proportional zum jeweiligen Interessengewicht
gesetzt wird.
4.2.3.3.3. Manipulation der Kugeldichte
Bei einer Skalierung der Abstandsberechnungsfunktion distance durch die unter
4.2.3.1. definierte Funktion scaling richtet sich die Positionierung der Dokumenten-
102

symbole jeweils nach dem am weitesten aussen in der Kugel positionierten Symbol.
Bei einer sehr ungleichen Verteilung der Dokumentensymbole kann dies dazu führen,
daß sich in der Nähe des Kugelmittelpunkts Gruppen von Dokumentensymbolen
bilden, deren Dokumente keinen hohen semantischen Verwandtschaftsgrad haben.
Die einzelnen Dokumente solcher Gruppen lassen sich nur schwer thematisch
einordnen.
Aus diesem Grund muß es dem Benutzer ermöglicht werden, die Symbole weiter
vom Kugelmittelpunkt zu entfernen. Dies kann durch eine Manipulation der Kugeldichte,
d.h. durch eine Änderung der Anziehungskraft der gesamten Kugeloberfläche
geschehen.
In der unter 4.2.3.1. definierten Funktion distance zur Berechnung des Abstandswerts
zwischen einem Dokument und einem Referenzpunkt muß die Variable density
eingeführt werden.
distance 3 (w, d)
count(w, d) relevanz(w) density
len(d)
scaling
Abbildung 3.28. verdeutlicht, wie eine Veränderung der Kugeldichte eine bessere
Verteilung der Dokumentensymbole zur Folge haben kann. Durch die Veränderung
der Situation aus Abbildung 3.25. hat sich die aus den Dokumenten d,e,f,g und h bestehende
Gruppe aufgelöst und der Benutzer kann die Dokumente klarer thematisch
einordnen.
house
a
h
d
g
f
e
b
energy
c
solar
Abbildung: 3.28.
Veränderung der Kugeldichte
103

4.2.3.3.4. Löschen von weniger relevanten Dokumenten
Das System nimmt unabhängig von ihren Relevanzwerten alle Dokumente, in denen
einer der referenzpunktbildenden Begriffe vorkommt, in die Ergebnismenge auf. Es
kann deshalb besonders bei sehr großen Datenbanken zu sehr großen und damit auch
mit einer graphischen Darstellung schwer überschaubaren Ergebnismengen kommen.
Aus diesem Grund muß es dem Benutzer möglich sein, die für seine Suchsituation
weniger relevanten Dokumente aus der Ergebnismenge zu löschen und damit die
Kardinalität der Ergebnismenge zu beeinflußen.
Wenn der Benutzer durch Positionierung und Gewichtung der Referenzpunkte die
ihm interessant erscheinenden Themensegmente gebildet hat, so ist davon auszugehen,
daß die weniger relevanten Dokumente innerhalb eines Themensegmentes in
der Nähe des Kugelmittelpunktes liegen (s. Abbildung 3.30.). Durch Löschen der
Dokumente, deren Symbole im Inneren einer kleineren Kugel um den Mittelpunkt
des Relevanzpunktes liegen, kann der Benutzer die Symbole weniger relevanter Dokumente
aus der Darstellung löschen.
Visualisiert werden kann ein solcher Löschvorgang durch eine im Radius veränderbare
Kugel um den Mittelpunkt der Darstellung (s. Abbildung 3.29.). Der Benutzer
kann dann interaktiv die Größe dieser ’Löschkugel’ bestimmen und durch eine Aktion
den Löschvorgang starten.
a
b
c
e
d
Der Benutzer kann die Größe der
Löschkugel interaktiv verändern
und durch Auslösen der Löschaktion
die Dokumente löschen, welche
sich im Inneren dieser Kugel befinden.
Im Beispiel der Darstellung würden
die Dokumente b,d und e aus der
Relevanzkugel entfernt.
f
g
Abbildung: 3.29.
Die ’Löschkugel’
104

min.
e d b c a f g max.
Relevanz
Abbildung: 3.30.
Relevanz der Dokumente
4.2.3.3.5. Löschen und Hinzufügen eines Referenzpunktes
Eine zweite Möglichkeit zur Beeinflussung der Ergebnismengenkardinalität ist das
Löschen einzelner Referenzpunkte.
Es muß dem Benutzer ermöglicht werden, einzelne Referenzpunkte auszuwählen
und aus der Referenzpunktmenge zu löschen. Nach dem Löschen eines der Referenzpunkte,
sollten alle Dokumente aus der Ergebnismenge entfernt werden, für die
keiner der in der Referenzpunktmenge verbleibenden Referenzpunkte relevant ist.
Die Symbole von Dokumenten, für welche sowohl der entfernte Referenzpunkt als
auch mindestens einer der in der Menge verbleibenden relevant ist, verbleiben in der
Darstellung und ändern lediglich ihre Position, da der durch den entfernten Referenzpunkt
erzeugte Anziehungsvektor nicht mehr in die Positionsberechnung aufgenommen
wird.
Abbildung 3.31. verdeutlicht die Positionsberechnung eines Dokumentensymbols
nach Entfernung eines für das betreffende Dokument relevanten Referenzpunktes.
Mit doc * ist in der Darstellung das Dokumentensymbol an der neuen Position bezeichnet
105

B
A
*
doc *
doc
C
D
*
Abbildung: 3.31.
Entfernung des Referenzpunktes B
Entsprechend sollte es dem Benutzer möglich sein, zusätzliche Referenzpunkte der
Darstellung hinzuzufügen. Wenn die Referenzpunkte durch einzelne Begriffe der
Datenbank definiert sind, kann ein solches Hinzufügen durch textuelle Eingabe des
betreffenden Begriffs realisiert werden.
Analog zur Entfernung eines Referenzpunktes sollten beim Hinzufügen alle Dokumente
der Datenbank zusätzlich in die Ergebnismenge aufgenommen werden, für
die der hinzugefügte Referenzpunkt relevant ist.
A
X
**
doc *
doc
D
C
*
**
*
Abbildung: 3.32.
Hinzufügen des Referenzpunktes X
106

Abbildung 3.32. verdeutlicht die Positionsberechnung eines Dokumentensymbols
nach dem Hinzufügen eines Referenzpunktes welcher für das betreffende Dokument
relevanten ist. Mit doc * ist das Dokumentensymbol an der neu berechneten Position
und mit ** der betreffende Positionsvektor.
In Abbildung 3.33. ist das Themensegment aus Abbildung 3.27. dargestellt, nachdem
der Referenzpunkt des Begriffes heat zur Referenzpunktmenge hinzugefügt
wurde.
Das Hinzufügen hatte im Beispielfall folgende Auswirkungen auf die Dokumente:
Die Symbole der Dokumente a, c, d, e, f und h ändern ihre
Position nicht. Der Begriff heat ist für diese Dokumente
nicht relevant
Die Symbole der Dokumente x, y, und z werden neu in die
Darstellung aufgenommen. Aufgrund ihrer Position
scheint nur der neue Referenzpunkt für die betreffenden
Dokumente relevant zu sein.
v und w sind ebenfalls neu in die Ergebnismenge aufgenommen,
werden aber auch von den anderen Referenzpunkten
beeinflußt
Die Dokumente b und g waren bereits in der Ergebnismenge
enthalten, werden aber auch von dem neuen Referenzpunkt
beeinflußt. Ihre Symbole ändern daher die Position.
107

house
h
x
y
f
e
z
w
a
v
b
g
d
c
energy
solar
heat
Abbildung: 3.33.
Hinzufügen des neuen Referenzpunktes heat
108

4.3. Präsentation des Dokumenteninhalts
In traditionellen Retrievalsystemen werden dem Benutzer die Dokumente der Datenbank
nur als bibliographische Einträge präsentiert. Das System liefert keine genauere
Information über den Inhalt. Der Benutzer kann nicht im Rahmen seiner Recherche
mit dem Retrievalsystem eine endgültige Dokumentenauswahl treffen.
In einer Volltextdatenbank sind nicht nur bibliographische Einträge, sondern komplette
Dokumente abgelegt. Es sollte dem Benutzer möglich sein, während der Erschließung
der Datenbank im Dialog mit dem Kontextbaum den Inhalt einzelner
Dokumente zu lesen. Während der Segmentierung der erschlossenen Dokumentenmenge
durch die Relevanzkugel sollte ebenfalls eine Darstellung des Inhalts eines
Dokuments der Menge möglich sein.
Zur Realisierung einer solchen Präsentation des Dokumenteninhalts wird im folgenden
die dritte Metapher der in dieser Arbeit vorgestellten graphischen Benutzerschnittstelle
definiert.
4.3.1. Der Dokumentenraum
In einer dreidimensionalen Darstellung bietet es sich an, die Metapher des ’Betretens’
eines Symbols zu wählen, wenn der Benutzer sich über Eigenschaften und Inhalt
desselben informieren will. Das ’Betreten’ eines Dokuments kann durch das Betreten
eines Raumes, auf dessen Wände das Dokument projeziert wird, realisiert
werden.
Auf der Definition eines solchen Raums basiert das Modell des Dokumentenraums.
Der Dokumentenraum bietet eine Umgebung, in welcher der Benutzer mit Hilfe von
Kontextbaum und Relevanzkugel den Retrievaldialog führen kann.
Das Modell des Dokumentenraums arbeitet folglich komplementär zu den beiden
Interaktionswerkzeugen, d.h. der Benutzer kann sich des Darstellungsraumes jederzeit
während der Interaktion mit Kegelbaum oder Relevanzkugel bedienen.
Da die beiden Werkzeuge aus Gründen der Übersichtlichkeit nicht gleichzeitig genutzt
werden sollten, ist immer nur eines der beiden aktiviert. Das nichtaktivierte
Werkzeug steht dem Benutzer immer in Form eines 3D-Icons im Dokumentenraum
zur Aktivierung zur Verfügung.
Abbildung 3.34. zeigt den aktivierten Dokumentenraum. Der Kontextbaum ist deaktiviert
und wird als 3D-Icon in der linken oberen Ecke des Raumes dargestellt. Die
Relevanzkugel ist im Beispiel der Abbildung aktiviert. Auf der Rückwand des Dokumentenraumes
wird der Inhalt des aktuellen Dokumentes der Dokumentenmenge
in der Relevanzkugel angezeigt.
109

Inhalt des aktuellen Dokuments
Wenn Kontextbaum oder Relevanzkugel aktiviert
sind, so existiert jeweils ein aktuelles Dokument.
Der Inhalt dieses Dokuments wird, so
wie dieser Text auf die Rueckwand des Dokumentenraumes
’projeziert’.
Abbildung: 3.34. Der Dokumentenraum
Die Raummetapher kann auch zur Präsentation von Elementen nichttextueller Datenbanken
verwendet werden. Voraussetzung ist, daß die Elemente der Datenbank
in einem Raum visualisiert werden können.
Bei einer Anwendung der Metapher auf eine Datenbank von bewegten oder statischen
Bildern läßt sich ein Videoraum definieren. In der Metapher des Videoraumes
kann die Rückwand, auf der im Dokumentenraum Texte präsentiert werden, zur
Darstellung der Bilder der Datenbank genutzt werden.
110

5. Realisierung eines Prototyps
Die Realisierung der drei oben beschriebenen Metaphern liegt in Form des Prototypen
’LyberWorld’ vor. Der Umgang mit dem Prototypen aus Sicht des Benutzers
wird im Kapitel 5.1. anhand eines Beispiels für eine Informationssuche vorgestellt.
Im Anschluß wird im Kapitel 5.2. der interne Aufbau des Systems erläutert.
Der Name ’Lyberworld’ entstand in Anlehnung an die Inhalte der Datenbank (liber
= Buch) und die verwendeten Visualisierungstechnologien (Cyberspace = der errechnete
Raum). Die Realisierungen der drei Metaphern heißen ’LyberTree’ (der
Kontextbaum), ’LyberSphere’ (die Relevanzkugel) und ’LyberRoom’ (der Dokumentenraum).
Als Datenbasis dient im folgenden Beispiel die CORDIS-Datenbank. Sie ist eine
Volltextdatenbank, in der etwa 800 Dokumente enthalten sind, die EG-Projekte beschreiben.
5.1. Eine Informationssuche mit LyberWorld
Abbildung: 4.1.
Startfenster von LyberWorld
111

Im LyberWorld-System stehen dem Benutzer die drei graphischen Metaphern als Interaktionswerkzeuge
zur Verfügung, mit denen er seine Datenbankanfrage formulieren
und die von der Datenbank gelieferte Ergebnismenge explorieren kann.
Nach dem Starten des Systems findet der Benutzer die in Abbildung 4.1. dargestellte
Startsituation vor. Die drei Interaktionswerkzeuge werden durch drei 3D-Icons repräsentiert.
In der linken oberen Ecke das Icon des LyberTrees, rechts oben das des
LyberSpheres und in der linken unteren Ecke das des LyberRooms.
Um die Informationssuche zu starten muß der Benutzer in das Eingabefenster in der
linken oberen Ecke einen Startbegriff eingeben mit dem er den Suchdialog im Kontextbaum
starten will. Dieser Startbegriff wird vom System nur akzeptiert, wenn es
sich um einen Begriff der Datenbank handelt.
5.1.1. LyberTree
Als erstes der drei Werkzeuge aktiviert der Benutzer nun den LyberTree, die Realisierung
des Kontextbaums.
Abbildung: 4.2.
Die Dokumentenebene des Begriffs energy.
Die erste Dokumentenebene des Baumes wird aus der Datenbank gelesen und als
Zylinder visualisiert, der aus Blättchen besteht, auf denen die Dokumententitel zu
lesen sind (Abbildung 4.2.). In diese erste Dokumentenebene werden alle Dokumente
der Datenbank aufgenommen, die den vom Benutzer eingegebenen Startbegriff
– im dargestellten Beispiel der Begriff energy – enthalten.
112

Der Benutzer kann den Dokumentenzylinder drehen und so auch die Titel der Dokumente,
deren Blättchen sich auf der Rückseite des Zylinders befinden, lesen. Er kann
ein ihm interessant erscheinendes Dokument anhand des Titels auswählen und ’expandieren’.
Durch dieses Expandieren eines Dokuments wird eine Begriffsebene
generiert, die alle für das Dokument relevanten Begriffe enthält. Die Begriffsebene
wird in der Visualisierung an das betreffende Dokumentenblättchen angehängt.
Abbildung 4.3. zeigt den Kontextbaum mit der ersten vom Benutzer expandierten
Begriffsebene.
Der Benutzer kann nun durch Expansion weiterer Begriffe oder Dokumente der Datenbank
den Kontextbaum erweitern und so den Bereich der Datenbank, der seinem
Suchinteresse entspricht, explorieren.
Abbildung: 4.3.
Expandieren des Dokumentes
Desweiteren hat er die Möglichkeit, neben dem Startbegriff weitere Schlüsselbegriffe
einzugeben. Falls der hinzugefügte Schlüsselbegriff bereits in einer Begriffsebene
des Baumes erscheint, so wird diese Ebene aktualisiert und das Blättchen des
neuen Schlüsselbegriffs in den Vordergrund rotiert.
Im Falle, daß der Schlüsselbegriff noch in keiner Begriffsebene des Baumes auftaucht,
wird an alle Dokumentenblättchen, deren Dokumente den Begriff enthalten,
ein ’Auswahlkonus’ angehängt. Der Benutzer wird so in der Auswahl des zu expandierenden
Dokuments unterstützt. Wenn er ein mit einem Auswahlkonus gekennzeichnetes
Dokumentenblättchen expandiert, so wird in der dadurch an den Baum
angehängten Begriffsebene der eingegebene Schlüsselbegriff automatisch aktualisiert
und expandiert.
113

Abbildung 4.4. zeigt den Kontextbaum nach Eingabe des Schlüsselbegriffs house.
An die Dokumentenblättchen der Dokumente in welchen der Begriff house vorkommt,
ist jeweils ein Auswahlkonus angehängt.
Abbildung: 4.4.
Auswahlkonen zur Dokumentenauswahl
114

Abbildung: 4.5.
Der Kontextbaum des kompletten Beispieldialogs
Wenn Begriffe oder Dokumente, die bereits in Ebenen des aktuellen Baumes auftauchen,
auch in eine neu expandierte Ebene aufgenommen werden, so haben die betreffenden
Blättchen der neuen Ebene ein etwas anderes Erscheinungsbild. Die
Blättchen sind kleiner und ihre Farbe ist heller als die der normalen Ebeneneinträge
(s. Kapitel 4.1.5.1.).
Wenn der Benutzer nun versucht eine solche Wiederholung eines Dokuments oder
eines Begriffs zu expandieren, so wird an der Stelle im Baum expandiert an der das
Element zum erstenmal eingehängt ist. Diese Vorgehensweise verhindert Orientierungsprobleme,
da der Benutzer nicht ’im Kreis laufen’ kann. Zu jedem Dokument
und zu jedem Begriff kann es im Baum nur eine Folgeebene geben.
Durch den Suchdialog im Kontextbaum hat der Benutzer eine Menge von Begriffen
definiert, die als Referenzpunkte in die Relevanzkugel übernommen werden können.
In diese Begriffsmenge werden alle Begriffe übernommen, die im Baum expandiert
wurden. In unserem Beispielfall sind dies die Begriffe energy, solar, house und
humid.
5.1.2. LyberSphere
Durch Aktivierung des Icons des Interaktionswerkzeugs LyberSphere wird dieses
gestartet. Der LyberTree wird deaktiviert und steht wieder in iconifizierter Form zur
Verfügung.
115

Abbildung: 4.6.
Die aktivierte Relevanzkugel LyberSphere
Abbildung 4.6. zeigt die Relevanzkugel nach der Aktivierung durch den Benutzer.
Die Begriffe des Suchpfades im Kontextbaum definieren die vier Referenzpunkte,
die als kleinere Kugeln auf der Oberfläche der Relevanzkugel visualisiert werden.
Im Inneren der Kugel sind die Dokumentensymbole, die durch Bücher dargestellt
werden, positioniert.
Der Benutzer hat nun die Möglichkeit, die in Kapitel 4.2.3.3. beschriebenen Interaktionen
auszuführen und so die dargestellten Dokumentensymbole in Themensegmente
aufzuteilen.
Um die Referenzpunkte auf der Kugeloberfläche zu positionieren, wird mit der
Maus eines der Symbole ausgewählt und aktualisiert. Das jeweils aktuelle Referenzpunktsymbol
kann nun mit Hilfe des Spaceballs oder der Rotationsränder am unteren
linken Fensterrand bewegt werden.
Abbildung 4.7. zeigt die Referenzkugel aus Abbildung 4.6., nachdem die Referenzpunkte,
die durch die Schlüsselbegriffe solar und house definiert sind, auf die rechte
Seite der Kugel bewegt wurden. Man sieht, daß die betreffenden Dokumentensymbole
der Referenzpunktbewegung folgen.
116

Abbildung: 4.7.
Positionierung der Referenzpunkte solar und house
Auch die Veränderung der Anziehungskraft einzelner Referenzpunkte, d.h. die Veränderung
des in Kapitel 4.2.3.3.2. eingeführten Relevanzwertes relevanz(w) wirkt
auf das jeweils aktuelle Referenzpunktsymbol. Mit dem ’Attraction’-Schieber am
rechten unteren Fensterrand kann der Benutzer den Relevanzwert variieren.
Mit dem neben dem ’Attraction’-Schieber positionierten ’Density’-Schieber kann
der Wert der in Kapitel 4.2.3.3.3. eingeführten Variablen density manipuliert und damit
die Anziehungskraft der gesamten Kugeloberfläche bestimmt werden. Durch eine
solche Manipulation der Kugeldichte ist es dem Benutzer möglich, die Dokumente
weiter vom Kugelmittelpunkt zu entfernen.
Wenn, wie in der Situation in Abbildung 4.8., keines der Referenzpunktsymbole aktualisiert
ist, so kann der Benutzer mit Spaceball oder Rotationsrädern die gesamte
Kugel frei rotieren. Er kann sich so besser mit den räumlichen Gegebenheiten der
Darstellung vertraut machen.
117

Abbildung: 4.8.
Rotation der gesamten Kugel
Wie bereits oben beschrieben, ist das Ziel der Interaktionen mit der Relevanzkugel
eine Aufteilung der Dokumentensymbole in verschiedene Themensegmente. In unserem
Beispielfall interessiert sich der Benutzer besonders für die Dokumente, deren
Symbole sich im von den Referenzpunkten solar und house gebildeten Themensegment
befinden. In Abbildung 4.9. ist dieses Themensegment markiert.
Im Idealfall enthält das so gebildete Themensegment alle Dokumente, die für das
Suchinteresse des Benutzers relevant sind. Der Benutzer kann sich nun, um sich mit
den Inhalten der Dokumente dieses Segments vertraut zu machen, des dritten Interaktionswerkzeugs,
des Dokumentenraums, bedienen.
118

Abbildung: 4.9.
Themensegment der Referenzpunkte solar und house
5.1.3. LyberRoom
Die Realisierung des Interaktionswerkzeugs des Dokumentenraums im Lyber-
World-System heißt ’LyberRoom’. Diese dritte Metapher arbeitet komplementär zu
den beiden ersten Werkzeugen. Der LyberRoom kann zeitgleich mit LyberTree oder
LyberSphere aktiviert sein.
Um die Inhalte der Dokumente des mit der Relevanzkugel erzeugten Themensegments
zu untersuchen, startet der Benutzer den Dokumentenraum durch Anklicken
des betreffenden Icons. Wie in Abbildungen 4.10. und 4.11. zu sehen ist, wird auf
der Rückwand des Dokumentenraumes das jeweils aktuelle Dokument der Relevanzkugel
oder Kontextbaumdarstellung angezeigt. Es ist so während Suchdialog
und Segmentierung der Dokumente möglich, den Inhalt zu lesen.
Abbildung 4.12. zeigt das System nach Abschluß der Informationssuche. Die beiden
Interaktionswerkzeuge sind deaktiviert und stehen dem Benutzer als aktivierbare
3D-Icons zur Verfügung. Auf der Rückwand des Dokumentenraums bleibt das zuletzt
in einem der Werkzeuge aktuelle Dokument stehen.
119

Abbildung: 4.10.
Dokumentenraum mit aktivierter Relevanzkugel
Abbildung: 4.11.
Dokumentenraum mit aktiviertem Kontextbaum.
120

Abbildung: 4.12.
Präsentation des gesuchten Dokuments.
121

5.2. Aufbau von LyberWorld
Der LyberWorld-Prototyp wurde als C++ Programm auf einer Unix Plattform entwickelt.
Als Entwicklungsumgebung standen Workstations der Firma Silicon Graphics,
das Betriebssystem ’IRIX 4.0.5’ und der Compiler ’Silicon Graphics C++
Compiler Version 3.0’ zur Verfügung. Als Hilfsmittel für die Visualisierung diente
IRIS Inventor in Version 1.0.1. Das Retrieval System INQUERY wurde in Version
1.5 vom Information Retrieval Laboratory des MIT auf Silicon Graphics Umgebung
portiert und zur Verfügung gestellt.
Der Prototyp besteht aus vier verschiedenen Modulgruppen. Drei dieser Gruppen
enthalten die Realisierungen der drei verschiedenen Interaktionswerkzeuge des Systems.
Die vierte Modulgruppe enthält Objekte für die Steuerung der Werkzeuge
und zur Koordination des Gesamtsystems. Den Modulgruppen sind Namen und
Kürzel zugeordnet, um eine Zuordnung von Dateien, wichtigen Klassen und Funktionen
zu ihrer Modulgruppe zu ermöglichen.
Modulgruppe Präfix Aufgabe
LyberWorld LW_ Steuerung und Koordination
LyberTree LT_ Kontextbaum
LyberSphere LS_ Relevanzkugel
LyberRoom LR_ Dokumentenraum
Abbildung 4.13. gibt einen Überblick über das Zusammenwirken der Modulgruppen.
Im anschließenden Abschnitt wird näher auf die Klassen der einzelnen Modulgruppen
eingegangen. Im zweiten Abschnitt wird der Aufbau des Inventor Szenengraphen
erläutert und im dritten Abschnitt werden Erweiterungsmöglichkeiten des
Systems aufgezeigt.
122

LyberWorld
Input
Steuerkommandos– und Daten
interface
LW_Main
LW_Callbacks
INQUERY
client
InquilList
LyberTree
LT_Main
LT_Callbacks
LT_Module
LyberSphere
LS_Main
LS_Callbacks
LS_Module
LyberRoom
LR_Main
LR_Callbacks
LR_Module
Visualisierungsdaten– und Anweisungen
Anfragen, Übergabedaten
Ereignis
Videodaten
Inventor
Szenengraph
LW_Viewer
Renderer
Keyboard
Mouse
Space ball
Space mouse
Menus
Sliders
Wheels
Buttons
Output
Bildschirm
Stereo Display
Abbildung: 4.13.
Modulgruppen
123

5.2.1. Die Klassenhierarchie
In diesem Kapitel werden die wichtigsten Klassendefinitionen und ihre Hierarchie
beschrieben. Zu Beginn jeden Abschnitts sind die wichtigsten Klassen der Modulgruppe
in einer Graphik dargestellt. In die tabellarischen Klassenbeschreibungen
wurde jeweils nur eine Auswahl der wichtigsten Methoden und Felder aufgenommen.
5.2.1.1. Die Modulgruppe: ’LyberWorld’
Interface
Klasse zu Kontrolle des Systemzustandes und Vermittlung der Benutzerinteraktionen
ROList
DynamicList
Basisklasse zur Beschreibung der Datenstruktur
einer Dynamischen Liste von
Klasseninstanzen
InquiElement
InquiList
Klassen zur Realisierung des Datenaustauschs zwischen den Interaktionswerkzeugen
TransitRec
Concept
DictRec
DocIX
Klassen zur Anbindung an INQUERY
ID2TitelDB
ID_DB
DocDB
ConceptDB
DocID_DB
TermID_DB
Die LyberWorld-Modulgruppe enthält Klassen zur Steuerung und Koordination des
Gesamtsystems. Dazu gehören Klassen zur Speicherverwaltung, zum Datenaustauch
zwischen den Interaktionswerkzeugen und zur Anbindung an INQUERY.
5.2.1.1.1. Klasse Interface
Klasse
Basisklassen
Interface
keine
124

Methoden
static void InitModules()
bool ChangeState(State newstate)
char*
State
InquiList*
SoXtViewer*
GetText()
GetState()
GetInqui()
GetViewer()
SoEventCallback* GetEventCB()
SoSelection* GetSelroot()
SoSeparator* GetRoomSep()
SoSeparator* GetSphereSep()
SoSeparator* GetTreeSep()
Typen
void SetText(char *text);
void SetInqui(InquiList* i inqui)
enum State
{ NothingActive
RoomActive
SphereActive
TreeActive
RoomTreeActive
RoomSphereActive
}
enum Command
{
ACTIVATE
DEACTIVATE
}
Felder
(private)
Die Klasse Interface koordiniert die verschiedenen Interaktionswerkzeuge. Dazu
gehört der Datenaustausch zwischen den Modulen, die Verwaltung des Systemzustands
und der Callbackfunktionen für die möglichen Benutzerinteraktionen.
Der Datenaustauch ist durch die Set- und Get-Funktionen realisiert. Mittels der Set-
Funktionen können Daten in die internen Felder der Interface–Klasse eingetragen
werden und mittels der Get-Funktionen wieder abgerufen werden. Erhält zum Beispiel
das Werkzeug LyberTree das Kommando DEACTIVATE, so stellt dieses mit
der Methode SetInqui(inquilist) Daten über den Suchdialog ein, bevor es in den deaktivierten
Zustand übergeht. Erhält im Anschluß das LyberSphere-Werkzeug das
Kommando zur Aktivierung ACTIVATE, kann es mittels der Methode GetInqui()
auf die Daten zugreifen.
125

Der Szenengraph, der die gesamte Visualisierung definiert, ist in verschiedene Teile
gruppiert. Jedem der Werkzeuge ist dabei ein Unterbaum des Graphen zugeordnet,
innerhalb dessen das Werkzeug seine Visualisierung beeinflussen kann. Durch die
Methoden GetTreeSep(), GetSphereSep() und GetRoomSep() erhalten die Werkzeuge
Zugriff auf die Wurzel ihres Teilbaums. Der Aufbau des Szenengraphen ist in Kapitel
5.2.2. genauer erläutert.
Weitere Unterbäume betreffen die Verwaltung der Callback-Funktionen und der Selektierbarkeit
von Visualisierungselementen. Ihre Wurzeln sind durch GetEventCB()
und GetSelRoot() zugänglich.
Das LyberWorld-System kann sich in sechs verschiedenen Systemzuständen befinden:
1. NothingActive: Keines der Interaktionswerkzeuge ist aktiviert.
2. RoomActive: Der Dokumentenraum ist aktiviert.
3. SphereActive: Die Relevanzkugel ist aktiviert.
4. TreeActive: Der Kontextbaum ist aktiviert.
5. RoomTreeActive: Der Dokumentenraum und der Kontextbaum
sind aktiviert
6. RoomSphereActive: Der Dokumentenraum und die Relevanzkugel
sind aktiviert.
Wenn der Benutzer eines der Werkzeuge aktiviert oder deaktiviert, ändert das Benutzerinterface
den aktuellen Systemzustand durch die Methode ChangeState(). Dazu
hat ChangeState() Zugriff auf die vereinheitlichten Steuerungsschnittstellen der
Werkzeuge.
Werkzeug Steuerschnittstelle Kommentar
Kontextbaum
Relevanzkugel
Dokumentenraum
LT_Main(int argc, char
*argv[], interface *if)
LT_Main(int cmd, interface
*if)
LS_Main(int argc, char
*argv[], interface *if)
LS_Main(int cmd, interface
*if)
LR_Main(int argc, char
*argv[], interface *if)
LR_Main(int cmd, interface
*if)
Einmalige Initialisierung bei
Systemstart
Kommandoschnittstelle
Einmalige Initialisierung bei
Systemstart
Kommandoschnittstelle
Einmalige Initialisierung bei
Systemstart
Kommandoschnittstelle
Abhängig vom aktuellen Systemzustand leitet das Benutzerinterface die Benutzerinteraktionen
an die verschiedenen Module weiter. Im Prototyp des Systems wirden
126

eine große Zahl verschiedener Benutzerinteraktionen verwaltet. Die wichtigsten Interaktionen
und zugeordneten Ereignisse sind:
1. KeyboardEvent: Ereignis einer Tastatureingabe.
2. SpaceBallMotionEvent: Ereignis einer Bewegung des
Spaceballs.
3. SpaceBallButtonEvent: Ereignis einer Eingabe über die
Spaceballtasten.
4. MousePickEvent: Mausauswahlereignis.
5. LeftSliderEvent: Ereignis einer Bewegung des linken
Schiebers auf dem unteren Fensterrand.
6. RightSliderEvent: Ereignis einer Bewegung des rechten
Schiebers.
7. LeftWheelEvent: Ereignis einer Bewegung des linken
Rades auf dem linken Fensterrand.
8. RightWheelEvent: Ereignis einer Bewegung des rechten
Rades auf dem unteren Fensterrand.
9. MenuEntryEvent: Ereignis einer Auswahl eines Menüeintrags
10. HelpEvent: Ereignis der Betätigung des Hilfeknopfs auf
dem rechten Fensterrand.
11. SetHomeEvent: Ereignis der Betätigung des Sethome-
Knopfs auf dem rechten Fensterrand.
12. BackHomeEvent: Ereignis der Betätigung des Backhome-
Knopfs auf dem rechten Fensterrand.
Beim Auftreten eines der Ereignisse wird die entsprechende Callbackfunktion aufgerufen.
In Abhängigkeit vom aktuellen Systemzustand und vom Typ des
Ereignisses werden die Ereignisschnittstellen der betroffenen Module aufgerufen.
Die Ereignisschnittstellen der Werkzeuge sind Funktionen, deren Namen mit dem
Gruppenpräfix beginnen und mit dem restlichen Namen mit dem der Callbackfunktion
übereinstimmen. Die Parameter der Schnittstellenfunktionen sind identisch mit
denen der zugehörigen Callbackfunktionen. Die Ereignisschnittstelle des Kontextbaums
zur Behandlung von Tastatureingaben heißt LT_KeyboardEvent().
5.2.1.1.2. Klasse DynamicList
Klasse
Basisklassen
DynamicList
ROList
127

Methoden
Felder
void DelCurItem()
void DelAllItems()
void DelLastItem()
void AddItem(void *NewItem)
void AddList(DynamicList *DList)
void InsertBefore(void *OldItem, void *NewItem)
Felder und Methoden zum Aufbau der Liste werden
von der Basisklasse ROList geerbt
Die Klasse DynamicList ist eine Basisklasse zur Definition dynamischer Listen verschiedenster
Elemente. Sie stellt Methoden zum Löschen und Hinzufügen einzelner
Elemente zur Verfügung.
Mit dem Makro CASTDYNAMICLIST(a) wird in der Definition der Klasse
DynamicList der Typ a der Listenelemente festgelegt und mit TYPE-
DYNAMICLIST(a,b) kann eine dynamische Liste b aus Elementen vom Typ a definiert
werden.
Diese Art der Listendefinition wird in der LyberTree-Modulgruppe verwendet, um
die Begriffs- und Dokumentringklassen abzuleiten. In der LyberSphere-Modulgruppe
werden die Referenzpunkt- und Dokumentenmengen als dynamische Listen
definiert (s. Kapitel 5.2.1.2. und 5.2.1.3.).
Auch das im folgenden definierte Datenaustauschformat zwischen den Interaktionswerkzeugen
LyberTree und LyberSphere ist in Form einer dynamischen Liste definiert.
5.2.1.1.3. Klasse InquiElement
Klasse
Basisklassen
InquiElement
keine
128

Methoden
InquiEle();
InquiEle(int TID, char *TN, int DID, char *DN,
int REL);
void
int
SetConceptID(int TID)
GetConceptID()
char * GetConceptName()
void SetConceptName(char *name)
void
int
char
void
void
int
SetDocID(int DID)
GetDocID()
*GetDocName()
SetDocName(char *name)
SetRelevanceConceptID(int REL)
GetRelevance()
Felder
(private)
Beim Austausch der Daten zwischen den beiden Werkzeugen müssen jeweils Paare
von Begriffen und Dokumenten übergeben werden. Die Klasse InquiElement, die
ein Element der Übergabeliste definiert, stellt darum Funktionen zur Verfügung, mit
denen alle nötigen Informationen, Begriffs- und Dokumentnummer, Begriffs- und
Dokumentname sowie Relevanzwert eingegeben und wieder ausgelesen werden
können.
5.2.1.1.4. Klasse InquiList
Klasse
Basisklassen
Methoden
Felder
InquiList
ROList > DynamicList
Funktionen zum Schreiben und Lesen der Felder
Wortspezifische Festlegungen
Die Klasse InquiList wird mit dem Definitionsmakro TYPEDYNAMICLIST(InquiElement,InquiList)
festgelegt und ist eine dynamische Liste von Instanzen der
Klasse InquiElement.
5.2.1.1.5. Klasse TransitRec
Klasse
Basisklassen
TransitRec
keine
129

Methoden
Felder
TransitRec(char *Zeile_der_Transitionsdatei)
int GetDocID()
int GetConceptID()
int GetFreq()
private
Das INQUERY-Inhaltsnetz ist in Form einer Transitionsdatei (s. 3.6.2.7.) gespeichert,
in der jede Kante des Inhaltsnetzes durch eine Zeile vertreten ist. Eine solche
Zeile beinhaltet die Nummern der durch die Kante verbundenen Begriffs- und Dokumentknoten,
sowie die Vorkommenshäufigkeit des Begriffs im Dokument. Dem
Konstruktor der Klasse TransitRec wird eine Zeile der Datei übergeben. Mit den Lesemethoden
kann auf die Werte zugegriffen werden.
5.2.1.1.6. Klasse Concept
Klasse
Concept
Basisklassen keine
Methoden char *GetConcept()
int GetConceptID()
int GetFreq()
int GetDocFreq()
Felder
protected
Die Klasse Concept repräsentiert einen Begriff. Er besteht aus textuellem Namen,
Nummer, absoluter Vorkommenshäufigkeit und Anzahl der involvierten Dokumente.
Die Felder der Klasse Concept werden von folgender Klasse gefüllt.
5.2.1.1.7. Klasse DictRec
Klasse
DictRec
Basisklassen Concept
Methoden int NewDictRec(char *DictStr)
Felder
keine
INQUERY speichert das Ergebnis seines Begriffsparsers in einer Wörterbuchdatei
(s. 3.6.2..). Eine Zeile der Datei beinhaltet die Begriffsinformation, die von der Methode
NewDictRec(Wörterbuchzeile) in die Felder der Basisklasse Concept eingestellt
wird.
Klasse
Basisklassen
ID2TitelDB
keine
130

Methoden
Felder
virtual char *ID2Titel(int ID)
keine
Innerhalb von INQUERY und LyberWorld werden Begriffe und Dokumente in
Form von Nummern repräsentiert. Dies erlaubt platzsparende Speicherung und effiziente
Bearbeitung. Zur Rückgewinnung der textuellen Repräsentation dient die
Klasse ID2TitelDB.
Klasse
Basisklassen
Methoden
Felder
ConceptDB
ID2TitelDB
char* ID2Titel(int ConceptID);
Concept *SearchConcept(char *conceptname);
private
Die Klasse ConceptDB erlaubt den Zugriff auf das Begriffswörterbuch. Mit der Methode
ID2Titel(Begriffsnummer) erhält man den zur Begriffsnummer gehörenden
Begriff in textueller Form. Mit der Methode SearchConcept(Begriffstext) kann man
nach einem bestimmten Begriff suchen, was bei einer textuellen Suchworteingabe
durch den Benutzer nötig ist.
Klasse
Basisklassen
Methoden
Felder
DocDB
ID2TitelDB
char* ID2Titel(int DocID)
char* ID2Text(int DicID)
private
Die Klasse DocDB erlaubt den Zugriff auf die Dokumentendatenbank. Sie stellt Methoden
zur Verfügung, um anhand einer Dokumentennummer den Titel oder den
Text eines Dokuments zu erhalten.
Klasse
Basisklassen
Methoden
Felder
DocIX
keine
static long GetPos(int DocId)
private
Die Klasse DocIX erlaubt einen schnelleren Zugriff auf die Dokumentendatenbank.
Intern legt DocIX eine Tabelle von Dateipositionen an, so daß anhand der Dokumentennummer
direkt die Zielposition in der Dokumentendatenbank ermittelt werden
kann. Innerhalb der Methoden der Klasse DocDB wird durch Aufrufen der Methode
GetPos(Dokumentennummer) von dieser beschleunigten Zugriffsmöglichkeit Gebrauch
gemacht.
131

5.2.1.1.8. Klasse ID_DB
Klasse
Basisklassen
Methoden
Felder
ID_DB
keine
ID_DB(char *DBName)
void StartBrowse()
int Browse()
void EndBrowse()
virtual int FilterOK(char *line)
int GetActID()
int GetSearchID()
int GetActFreq()
(private)
Die Klasse ID_DB ist die Basisklasse für den Zugriff auf Datenbankinformation auf
der Basis von Dokument– oder Begriffsnummern. Durch die virtuelle Funktion FilterOK
können erbende Klassen entscheiden, ob das jeweilige Element ausgegeben
werden soll oder nicht. Eine Redefinition von FilterOK muß eine Funktion sein, die
als Parameter eine Zeile der Transitionsdatei erhält und als Rückgabewert TRUE liefert,
falls die übergebene Zeile das jeweilige Suchkriterium erfüllt. In dieser Basisklasse
wird jede nichtleere Eintragung in der Datenbank mit TRUE bewertet.
5.2.1.1.9. Klasse DocID_DB
Klasse
Basisklassen
Methoden
Felder
DocID_DB
ID_DB
DocID_DB();
void StartBrowse(Document *doc);
private: int FilterOK(char *line)
keine
Die Klasse DocID_DB erlaubt Zugriff auf Dokumentinformation anhand von Dokumentennummern.
Hauptaufgabe der Klasse ist die Bestimmung aller Begriffe, die
in einem bestimmten Dokument vorkommen. Diese Funktionalität wird für den
Aufbau der Begriffsringe benötigt. Mit der Methode StartBrowse(Dokument) wird
dazu ein bestimmtes Dokument spezifiziert und die Browse-Funktion initialisiert.
Im als Parameter übergebenen Dokument muß zumindest die Dokumentennummer
eingetragen sein. Durch wiederholtes Aufrufen der Methode Browse() werden alle
Kanten des Inhaltsnetzes bestimmt, die vom angegebenen Dokument ausgehen. Die
Begriffsnummer des Begriffs am anderen Ende der Kante wird als Rückgabewert
von Browse() zurückgegeben. Der Rückgabewert von Browse() ist negativ, wenn alle
Begriffsnummern abgearbeitet wurden.
Browse() findet die zu einem bestimmten Dokument gehörenden Eintragungen in
der Datenbank durch Redefinition der Funktion FilterOK. Die Filterfunktion extra-
132

hiert die Dokumentennummer aus der übergebenen Datenbankzeile und vergleicht
sie mit dem Wert von GetSearchID(). Bei Gleichheit ist der Rückgabewert TRUE.
5.2.1.1.10. Klasse ConceptID_DB
Klasse
Basisklassen
Methoden
Felder
ConceptID_DB
ID_DB
ConceptID_DB()
void StartBrowse(Word *word)
private: int FilterOK(char *line)
keine
Analog zur vorherigen Klasse erlaubt diese Klasse den Zugriff auf Begriffsinformationen
anhand von Begriffsnummern. Mit StartBrowse(Wort) wird ein bestimmtes
Suchwort spezifiziert. Die folgenden Aufrufe von Browse() liefern alle Dokumente
des Inhaltsnetzes, die durch eine Kante mit dem Suchwort verbunden sind. Die Sortierung
ergibt sich aus der Reihenfolge der Eintragungen, welche in absteigender
Relevanz vorliegt.
Die Redefinierte Funktion FilterOK extrahiert die Begriffsnummer aus der übergebenen
Datenbankzeile und vergleicht sie mit dem Wert von GetSearchID(). Bei
Gleichheit ist der Rückgabewert TRUE.
5.2.1.1.11. Klasse Query
Klasse
Basisklassen
Methoden
Felder
Query
keine
Query(Word *word)
void StartBrowse(Word *word);
int Browse(Document &Doc)
keine
Mit Hilfe der Klasse Query können die in Kapitel 3.2. beschriebenen, elementaren
Anfragen an das Retrieval System gestellt werden. Durch den Aufruf des Konstruktors
Query(Suchwort) wird die Evaluierung einer Anfrage mit dem Suchwort durch
INQUERY ausgelöst und die Browse-Funktion initialisiert. Die generierte Liste der
als relevant befundenen Dokumente wird von Query gespeichert. Durch wiederholtes
Aufrufen von Browse(Dokument) werden die Dokumente in die Referenzvariable
Dokument eingetragen, wobei das Dokument mit der höchsten Relevanzbewertung
an erster Stelle steht und dann der Rest in absteigender Ordnung folgt. Der
Rückgabewert von Browse ist die Nummer des aktuellen Dokuments oder eine negative
Zahl falls die Liste abgearbeitet ist. Nach einem Aufruf des Konstruktors
133

Query() mit einem Suchwort, ist das Browsing initialisiert und ein Aufruf von Start-
Browse() mit dem gleichen Wort wirkungslos. Ein Aufruf von StartBrowse() mit einem
anderen Suchwort löst eine neue Anfrage aus und reinitialisiert die Browse-
Funktion. Die Klasse verhält sich dadurch konsistent zu den Klassen DocID_DB und
ConceptID_DB.
5.2.1.2. Die Modulgruppe: ’LyberTree’
RingElement
Ring
Tree
Document
Word
DocRing
WordRing
Klassen zur Beschreibung des logischen
Kontextbaumes.
VisualBase
VisualElement
VisualRing
FaceRingShape
VisualTree
VisualTreeIcon
VisualDoc
VisualWord
VisualWordRing
VisualDocRing
Klassen zur Beschreibung
der graphischen
Objekte des Kontextbaumes.
Die LyberTree-Modulgruppe enthält die Klassendefinitionen zur Beschreibung einer
Kontextbaumrealisierung.
Die Klassenhierarchie ist in zwei Klassengruppen unterteilt, die zum einen Funktionen
zur Beschreibung des logischen Kontextbaumes und zum anderen Funktionen
zur Beschreibung seiner graphischen Beschaffenheit enthalten.
5.2.1.2.1. Klasse RingElement
Klasse
Basisklassen
RingElement
keine
134

Methoden
RingElement()
RingElement(char *Name, int ID)
char *GetName()
void SetName(const char *const NewName)
int GetID()
void SetID(int NewID)
REType GetType()
void SetLink(RingElement *DestREle);
void UnLink()
RingElement *GetLink()
int GetRef()
Ring
void
Ring
void
float
*GetHomeRing()
SetHomeRing(Ring *ring)
*GetChildRing()
SetChildRing(Ring *ring)
GetSize()
Felder
private
Die Klasse RingElement ist die Basisklasse für die logischen Dokument- und Begriffsbeschreibungen.
Sie enthält Festlegungen, welche für Dokumente und Worte
des Kontextbaumes gleich sind.
Neben den Informationen Typ, Name und Nummer stellt die Klasse Methoden zur
Verfügung mit denen Verweise auf Kopien des Ringelements (s. Kapitel 4.1.3.) verwaltet
werden (Link-Methoden). Get- und SetHomeRing() dienen der Zuordnung
des Elements zu einem Ring und Get- und SetChildRing() verwalten einen eventuellen
Unterring. Die Methode GetSize() berechnet den Platzbedarf des Elements unter
berücksichtigung eines eventuellen Unterbaums (s. Kapitel 4.1.4.).
Klasse
Basisklassen
Methoden
Felder
Klasse
Basisklassen
Methoden
Felder
Document
RingElement
Dokumentspezifische Methoden
private
Word
RingElement
Wortspezifische Methoden
private
Die Klassen Document und Word erben von der Basisklasse RingElement und ergänzen
weitere dokument- und begriffsspezifische Methoden.
135

5.2.1.2.2. Klasse Ring
Klasse
Basisklassen
Methoden
Ring
ROList > DynamicList > REleList
VisualConnect>VRConnect
Ring()
Felder
RingElement* GetInitREle()
float GetSize()
void Remove()
void RotForw()
void RotBack()
void RotOutside()
private
Die Basisklasse für die Beschreibung einer kompletten logischen Dokumenten- oder
Begriffsebene des Kontextbaumes heißt Ring. Eine Baumebene wird in Form einer
dynamischen Liste von Ringelementen festgelegt. Die Klasse Ring erbt folglich von
einer Klasse REleList, durch die eine dynamische Liste von Ringelementen beschrieben
wird. Durch die Erbschaft von der Klasse VRConnect wird die Verbindung
der logischen Ringbeschreibung zur konkreten Visualisierungsklasse VisualRing
hergestellt.
Die Methoden der Klasse dienen unter anderem zur Animation der einzelnen Baumebenen.
Mit RotForw() und RotBack() kann eine Rotation der Ebene realisiert werden,
während die Funktion RotOutside() dazu dient das jeweils aktuelle Element der
Ebene, nach vorne zu rotieren. Mit Remove() kann das jeweils aktuelle Element der
Ebene entfernt werden.
5.2.1.2.3. Klasse DocRing
Klasse
DocRing
Basisklassen REleList > Ring
Methoden void AddDoc(Document *NewDoc)
Felder
keine
Die Klasse DocRing ist eine Spezialisierung der Klasse Ring zur Beschreibung von
Dokumentenebenen des Kontextbaumes. Sie fügt der Basisklasse Ring lediglich die
Methode AddDocument() hinzu, mit der die Ringelementeliste um ein Dokument
erweitert werden kann.
5.2.1.2.4. Klasse WordRing
Klasse
Basisklassen
WordRing
REleList > Ring
136

Methoden
Felder
void AddWord(Word *NewWord)
keine
Die Klasse WordRing ist das Pendant zur Klasse DocRing und dient zur Beschreibung
von Begriffsebenen des Kontextbaums. Auch WordRing erweitert die Basisklasse
Ring lediglich um eine Methode AddWord() zur Erweiterung der dynamischen
Begriffsliste.
5.2.1.2.5. Klasse Tree
Klasse
Basisklassen
Methoden
Tree
VisualConnect > VTConnect
Tree()
void
void
Expand()
Remove()
void GoForw()
void GoBack()
void GoTo(RingElement *ToREle)
RingElement* GetRootREle()
Ring* GetCuRing()
void RotOutside()
Felder
InquiList* BuildInqui()
void ChangeRootword(Concept *rootconcept)
private
Zur logischen Beschreibung des gesamten Kontextbaumes ist im LyberTree-Modul
die Klasse Tree definiert. Tree enthält Methoden zur Manipulation des Baumes und
erbt von der Klasse VTConnect eine Verbindung zur Visualisierungsklasse Visual-
Tree.
Mit den Methoden GoForw() und GoBack() kann zwischen den Ebenen des Kontextbaumes
gewechselt werden. Die Bewegung bezieht sich jeweils auf das aktuelle
Element der aktuellen Ringebene. Expand() dient zum Expandieren des aktuellen
Elements. Mit Remove() kann die aktuelle Ebene mit ihren Tochterebenen aus dem
Baum entfernt werden. RotOutside() bewegt den gesamten Baum so, daß die aktuelle
Ebene in der Bildmitte und das aktuelle Element der Ebene im Vordergrund liegt.
Mit ChangeRootword() kann der Startbegriff des Kontextbaumes geändert werden.
Zu jeder der oben beschriebenen Klassen zur Kontextbaumdefinition ist eine Visualisierungsklasse
definiert, mit welcher die graphische Beschaffenheit des Baumes
137

und seiner Komponenten beschrieben wird. Die Visualisierungsklassen dienen zum
Aufbau des Inventor-Szenengraphen, mit dem die LyberWorld-Szene beschrieben
wird.
Die Visualisierungsklassen der LyberTree-Modulgruppe sind durch Klassennamen
gekennzeichnet, die mit dem Präfix ’Visual’ beginnen.
5.2.1.2.6. Klasse VisualElement
Klasse
Basisklassen
Methoden
VisualElement
VisualBase
VisualElement();
SoSeparator * GetGroup()
RingElement *GetREle()
void AddChildRing(SoGroup *grp)
void RemoveChildRing()
SoGroup * GetChildRing()
void
float
void
Refresh(float radius)
GetRotAngle()
SetRotAngle(float ang)
Felder
private
Die Visualisierungsklasse der logischen Klasse RingElement heißt VisualElement.
Jede Visualisierungsklasse dient zur Konstruktion eines Teilgraphen des Lyber-
World-Szenengraphen und enthält daher immer ein Methode GetGroup(), die den
Wurzelknoten dieses Teilgraphen zurückgibt. Weitere Methoden dienen dazu, einen
weiteren Ring an das Element anzuhängen (AddChildRing), ihn wieder zu entfernen
(RemoveChildRing) oder auf ihn zuzugreifen (GetChildRing). Mit der Methode Refresh(radius)
kann die Repositionierung des Ringelements an einen neuen Radius
ausgelöst werden, was infolge einer Spiralisierungsinteraktion durch den Benutzer
nötig ist. Get- und SetRotAngle() betreffen den Rotationswinkel des Elements innerhalb
seiner Ringgruppe.
5.2.1.2.7. Klasse VisualDoc
Klasse
Basisklassen
VisualDoc
VisualBase > VisualElement
138

Methoden
Felder
VisualDoc(Document *OneDoc, float yDist=0,
floatzDist=0)
keine
VisualDoc ist die Visualisierungsklasse der logischen Klasse Document. Der Konstruktor
VisualDoc() bewirkt den Aufbau eines Teilszenengraphen, der die Visualisierung
eines Dokumentenknoten beschreibt.
5.2.1.2.8. Klasse VisualWord
Klasse
Basisklassen
Methoden
Felder
VisualWord
VisualBase > VisualElement
VisualWord(Word *OneWord, float yDist=0,
floatzDist=0
keine
Entsprechend zu VisualDoc visualisiert VisualWord einen Begriffsknoten des Kontextbaumes.
5.2.1.2.9. Klasse VisualRing
Klasse
Basisklassen
Methoden
VisualRing
VisualBase
FaceRingShape
VisualRing();
SoGroup
*GetGroup()
Ring
float
void
void
void
void
*GetRing()
GetRotAngle()
SetRotAngle(float ang)
Refresh();
Highlight();
UnHighlight()
Felder
private
VisualRing ist die Basisklasse für die Visualisierungsklassen der Kontextbaumebenen.
139

Die Methode GetGroup() liefert die Wurzel des Teilszenengraphen und GetRing()
die logische Beschreibung des Rings. Get- und SetRotAngle() betreffen den Rotationswinkel
um den der gesamte Kegel, alle Ringelemente auf seiner Spirale und alle
nachfolgenden Baumebenen gedreht sind.
Die weiteren Methoden der Klasse erlauben An- und Abschalten der visuellen Hervorhebung
des aktuellen Elements und des aktuellen Rings (HighLight(), UnHigh-
Light()) und eine Auffrischung (Refresh()) der Darstellung, welche die graphische
Beschaffenheit an die aktuelle logische Beschaffenheit des Ringes anpaßt.
5.2.1.2.10. Klasse VisualDocRing
Klasse
Basisklassen
Methoden
Felder
VisualDocRing
VisualBase > VisualRing
VisualDocRing(DocRing *OneDocRing)
keine
5.2.1.2.11. Klasse VisualWordRing
Klasse
Basisklassen
Methoden
Felder
VisualWordRing
VisualBase > VisualRing
VisualWordRing(WordRing *OneWordRing)
keine
Die Klassen VisualDocRing und VisualWordRing erweitern ihre Basisklasse VisualRing
jeweils um den Konstruktor zur Konstruktion einer speziellen Dokumenten-
oder Begriffsebene. Anhand der logischen Ebenenbeschreibung wird durch die
Konstruktoren der Teilszenengraph des Ringes generiert.
5.2.1.2.12. Klasse VisualTree
Klasse
Basisklassen
Methoden
Felder
VisualTree
VisualBase
VisualTree(Tree *tree)
SoGroup* GetGroup()
void Refresh()
private
VisualTree ist die Visualisierungsklasse für die komplette graphische Kontextbaumbeschreibung.
140

Dem Konstrukor von VisualTree wird die logische Repräsentation des Kontextbaums
durch den Parameter tree übergeben. VisualTree stößt die Generierung des
Kontextbaumszenengraphen an, indem der Konstruktor von VisualElement mit dem
Wurzelknoten als Parameter aufgerufen wird. Findet dieser einen anhängenden
Ring, wird mit diesem der Konstruktor VisualRing aufgerufen, welcher wiederum
für alle seine Ringelemente VisualElement anstößt. Der Prozeß setzt sich rekursiv
fort, bis der Szenengraph des gesamten Baums aufgebaut ist. Mit der Methode Get-
Group() kann auf den Wurzelknoten des Szenengraphen zugegriffen werden.
5.2.1.2.13. Klasse VisualTreeIcon
Klasse
Basisklassen
Methoden
Felder
VisualTreeIcon
VisualBase
VisualTreeIcon()
SoSeparator* GetGroup()
private
Die Klasse VisualTreeIcon dient zur Beschreibung des Szenengraphen des Lyber-
Tree-Icons, welches die Baumdarstellung bei deaktiviertem LyberTree-Werkzeug
ersetzt.
5.2.1.3. Die Modulgruppe: ’LyberSphere’
SphereElement
SphereSet
Sphere
SphereWord
SphereDoc
WordSet
DocSet
Klassen zur Beschreibung der logischen
Relevanzkugel.
ViewBase
ViewElement
ViewSet
ViewSphere
ViewSphereIcon
ViewWord
ViewDoc
ViewWordSet
ViewDocSet
Klassen zur Beschreibung
der graphischen Objekte
der Relevanzkugel.
141

Wie in der LyberTree-Modulgruppe sind auch die Klassen der LyberSphere-Modulgruppe
in Klassen zur Beschreibung der logischen und der graphischen Beschaffenheit
der Relevanzkugel unterteilt.
5.2.1.3.1. Klasse SphereElement
Klasse
SphereElement
Basisklassen keine
Methoden SpherElement()
void SetName(char *name)
char * GetName()
void
int
void
int
SetID(int NewID)
GetActID()
SetType(SpEleType TYPE)
GetType()
Felder
private
Die Basisklasse zur Beschreibung eines Dokuments oder eines Referenzpunktes
heißt SphereElement. Die Methoden von SphereElement verwalten Informationen,
welche bei einer Dokument- und Referenzpunktbeschreibung gleich sind. Dies sind
die Festlegungen des Namens, der Nummer und des Typs.
5.2.1.3.2. Klasse SphereWord
Klasse
Basisklassen
Methoden
SphereWord
SphereElement
SphereWord(int WordID, char *WName)
Felder
DocList *DocLink
Die Klasse SphereWord dient zur Beschreibung der logischen Eigenschaften eines
Referenzpunktes. Sie erbt die Grundeigenschaften eines Elements von SphereElement
und enthält zusätzlich einen Zeiger auf eine dynamische Liste von Dokumenten
(DocLink), in der alle Dokumente eingetragen sind, für die der betreffende Referenzpunkt
relevant ist.
5.2.1.3.3. Klasse SphereDoc
Klasse
SphereDoc
Basisklassen SphereElement
142

Methoden
SphereDoc(int DocID, char *DName)
long
void
float
GetDocLength()
SetDocMag(float mag)
GetDocMag()
Felder long DocLenght
WordList * ConceptLink
Wie SphereWord wird auch die Klasse SphereDoc von SphereElement abgeleitet.
Sie enthält als zusätzliche Felder zur Dokumentenbeschreibung eine dynamische
Liste von allen für das betreffende Dokument relevanten Referenzpunkten (ConceptLink)
und Methoden für den Zugriff auf die Dokumentenlänge (Get-
DocLength()) und den Wert für die Anziehungskraft, mit der das Dokumentensymbol
aus dem Mittelpunkt der Relevanzkugel herausgezogen wird (Get- und
SetDocMag()).
5.2.1.3.4. Klasse SphereSet
Klasse
Basisklassen
Typen
Methoden
SphereSet
keine
enum SpEleType
{ SPHEREvoid
SPHEREword
SPHEREdoc
}
SphereSet()
SpEleType GetType()
void SetType(SpEleType type)
void SetInitEle(SphereElement)
int
GetEleNumber()
Felder
private
Die Basisklasse zur Beschreibung der logischen Dokument- und Referenzpunktmengen
heißt SphereSet. Sie enthält die Methoden Set- und GetType() zum Festlegen
und Abfragen des Mengentyps SpEleType und die Methode SetInitEle() zur Zuordnung
des initialen Elements der Menge. Die Methode GetEleNumber() liefert die
Kardinalität der Menge. Diese Eigenschaften der Klasse werden an die zwei spezielleren
Mengenbeschreibungsklassen vererbt.
143

5.2.1.3.5. Klasse WordSet
Klasse
Basisklassen
Methoden
WordSet
SphereSet, ROList > DynamicList > WordList
WordSet(InquiList *IList, int MaxWordAnz)
SphereWord* GetWordWithIndex(int index)
SphereWord* GetWordWithID(int ID)
bool TestWordWithID(int ID)
Felder
private
Die Klasse WordSet dient zur Beschreibung der logischen Referenzpunktmenge in
der Relevanzkugel.
Die Referenzpunktmenge wird als dynamische Liste von Worten festgelegt. Die Eigenschaften
einer dynamischen Liste erbt WordSet von der Klasse WordList. Desweiteren
sind in WordSet Methoden definiert, mit denen ein Zugriff auf einzelne
Mengenelemente über ihre ID und ihren Listenindex möglich ist (GetWordWithIndex(),
GetWordWithID()). Die Methode TestWordWithID() testet das Vorkommen
eines Mengenelements anhand der ID.
5.2.1.3.6. Klasse DocSet
Klasse
Basisklassen
Methoden
DocSet
SphereSet, ROList > DynamicList >DocList
DocSet(InquiList *IList)
SphereDoc* GetDocWithID(int ID)
void ChangeFreqs(int WordID, float Radius)
Felder
long MaxDocLenght
SphereDoc *ActDoc
Entsprechend wird auch die logische Dokumentenmenge, welche durch die Klasse
DocSet definiert wird, als dynamische Liste von Dokumenten festgelegt.
DocSet erbt von der Klasse DocList, die eine solche dynamische Dokumentenliste
definiert. Zusätzlich zu den von SphereSet geerbten Eigenschaften enthält DocSet
Felder zur Festlegung des jeweils aktuellen Dokuments (ActDoc) und der Länge des
umfangreichsten Dokuments (MaxDocLenght).
Klasse
Basisklassen
Sphere
keine
144

Methoden
Sphere(float radius)
float
GetRadius()
Felder
private
Die Klasse Sphere ist zur Festlegung globaler Werte und Einstellungen der Relevanzkugel
vorgesehen. In der Version des Prototypen beinhaltet sie lediglich den
Wert des Radius der Relevanzkugel.
Die Visualisierungsklassen der LyberSphere-Modulgruppe sind durch das Präfix
’View’ im Klassennamen gekennzeichnet. Entsprechend der Klassen der Lyber-
Tree-Modulgruppe ist auch hier zu jeder logischen Klasse eine Visualisierungsklasse
definiert.
5.2.1.3.7. Klasse ViewElement
Klasse
Basisklassen
Methoden
ViewElement
ViewBase
ViewElement()
SoSeparator* GetGroup()
Felder
SoSeparator *Ele_Group
int ActID
Die Basisklasse der Visualisierungsklassen für einzelne Elemente, d.h. für Dokumenten-
und Referenzpunktsymbole, heißt ViewElement.
ViewElement liefert durch GetGroup() einen Zeiger auf den Wurzelknoten des
Teilszenengraphen der graphischen Symbolbeschreibung.
5.2.1.3.8. Klasse ViewWord
Klasse
Basisklassen
Methoden
Felder
ViewWord
ViewBase > ViewElement
ViewWord(SphereWord *OneWord, float x_deg,
float y_deg
void Add2DText(SphereWord *SW, SbVec3f TV)
void HighLight()
void UnHighLight()
keine
145

ViewWord ist die Klasse zur Beschreibung eines Referenzpunktsymbols.
Mit dem Konstruktor ViewWord() wird der Teilszenengraph angelegt, dessen Wurzelknotenzeiger
ViewWord von der Basisklasse ViewElement erbt. Desweiteren sind
in der Klasse Methoden zum Anhängen eines Textes Add2DText() und zum An- und
Abschalten der Hervorhebung des aktuellen Referenzpunktes HighLight(), Un-
HighLight() enthalten.
5.2.1.3.9. Klasse ViewDoc
Klasse
Basisklassen
Methoden
Felder
ViewDoc
ViewBase > ViewElement
ViewDoc(SphereDoc *OneDoc)
void HighLight()
void UnHighLight()
static ClosedBookKit *CBK
static OpenBookKit *OBK
ViewDoc ist die entsprechende Klasse zur Visualisierung eines Dokumentensymbols.
Auch in der Dokumentenmenge existiert jeweils ein aktuelles Element, dessen Symbol
als aufgeschlagenes Buch visualisiert wird. Die nicht aktuellen Dokumente werden
als geschlossene Bücher dargestellt. Folglich müssen zwei verschiedene
Teilszenengraphen definiert werden. Dies geschieht durch die Klassen ClosedBook-
Kit und OpenBookKit. In ViewDoc sind Zeiger auf statische Instanzen dieser Klassen
definiert (CBK, OBK).
Mit den Methoden HighLight() und UnHighLight() kann zwischen den beiden Symbolen
gewechselt werden.
5.2.1.3.10. Klasse ViewSet
Klasse
Basisklassen
Methoden
ViewSet
ViewBase
ViewSet()
SoSeparator* GetGroup()
Felder
private
ViewSet ist die Basisklasse zur Beschreibung der Visualisierung einer gesamten Elementmenge,
d.h. einer Dokumenten- oder Referenzpunktmenge.
146

Die Teilszenengraphen der einzelnen Elementensymbole werden in der Menge zu
einem Szenengraphen zusammengefügt. Mit GetGroup() kann auf den Zeiger des
Wurzelknotens zugegriffen werden.
5.2.1.3.11. Klasse ViewWordSet
Klasse
Basisklassen
Methoden
ViewWordSet
ViewBase > ViewSet
ViewWordSet(WordSet* wordset)
Felder
keine
Mit dem Konstruktor ViewWordSet() der Klasse ViewWordSet wird der Szenengraph
angelegt. Den Zeiger auf den Wurzelknoten erbt ViewWordSet von der Basisklasse
ViewSet.
5.2.1.3.12. Klasse ViewDocSet
Klasse
Basisklassen
Methoden
ViewDocSet
ViewBase > ViewSet
ViewDocSet(DocSet *OneDocSet,
WordSet *OneWordSet
ViewWordSet *VWS)
SbVec3f GetWordKoor(SoGroup *WordGrp,
SoGroup *SetGrp)
void
float
SetPercent(float wert)
GetPercent()
Felder
private
Entsprechend stellt die Klasse ViewDocSet Methoden zum Aufbau des Szenengraphen
der Dokumentengruppe zur Verfügung.
Der Szenengraphenaufbau durch ViewDocSet() benötigt Zeiger auf die logische und
graphische Beschreibungsklasse der Referenzpunktmenge, da die Dokumentensymbole
abhängig von den Positionen der Referenzpunkte und den jeweiligen Relevanzwerten
positioniert werden. Mit der Methode GetWordKoor() können die aktuellen
Koordinaten der Referenzpunktsymbole ermittelt werden, die zur
Berechnung der Positionen der Dokumentensymbole benötigt werden.
Der Rückgabewert der Methode GetPercent() ist der aktuelle Wert der eingestellten
Kugeldichte. Die Aktualisierung wird jeweils beim Aufruf der Callbackfunktion des
147

RightSliderEvent() anhand des aktuellen Werts des density-Schiebers durchgeführt.
SetPercent() legt damit die prozentuale Ausnutzung des Relevanzkugelinnenraumes
fest.
5.2.1.3.13. Klasse ViewSphere
Klasse
Basisklassen
Methoden
ViewSphere
ViewBase
ViewSphere(Sphere *Ball)
SoSwitch* GetGroup()
void ToggleBall()
void BallON()
void BallOFF()
Felder
private
Mit der Klasse ViewSphere wird die graphische Beschaffenheit der Relevanzkugeloberfläche
festgelegt.
Der Wurzelknoten des Teilszenengraphen den die Methode GetGroup() liefert, ist
vom Typ SoSwitch. Mit den Methoden ToggleBall(), BallON() und BallOFF() kann
die Darstellung der Kugeloberfläche ein- und ausgeschaltet werden.
5.2.1.3.14. Klasse ViewSphereIcon
Klasse
Basisklassen
Methoden
Felder
ViewSphereIcon
ViewBase
ViewSphereIcon()
SoSeparator *VSI_Group
Die Klasse VisualSphereIcon dient zur Beschreibung des Szenengraphen des LyberSphere-Icons,
welches die Relevanzkugeldarstellung bei deaktiviertem Lyber-
Sphere-Werkzeug ersetzt.
5.2.2. Der Szenengraph
Die graphischen Objekte des LyberWorld-Systems werden in Form eines IRIS Inventor
Szenengraphen gespeichert.
148

Die Konstruktoren der Visualisierungsklassen der einzelnen Objekte definieren jeweils
einen Teilszenengraphen und enthalten einen Zeiger auf den Wurzelknoten.
LyberWorld-Wurzel
Ereignisknoten
Baumwurzel Kugelwurzel Raumwurzel
Szenengraph
Szenengraph
Szenengraph
Szenengraph
Szenengraph
Szenengraph
des LyberTree-
des LyberTree-
des LyberSphe-
des LyberSphe-
des
des
Lyber-
Lyber-
Moduls
Icons
re-Moduls
re-Icons
Room-Moduls
Room-Icons
Deaktivierter Teilszenengraph eines der Interaktionswerkzeuge
oder seines Icons
Aktivierter Teilszenengraph eines der Interaktionswerkzeuge
oder seines Icons
Abbildung: 4.14.
Der Szenengraph des LyberWorld-Systems
Abbildung 4.14. zeigt die Wurzelkonstruktion des gesamten LyberWorld-Szenengraphen.
Der Gruppenknoten LyberWorld-Wurzel ist ein Selektionsknoten, d.h. bei
der Auswahl eines beliebigen Knotens des Szenengraphen, zum Beispiel interaktiv
durch die Maus, wird der Callbackfunktion ein Pfad vom Selektionsknoten zum ausgewählten
Knoten als Parameter geliefert. Wie in Kapitel 2.2.3.2. beschrieben, können
so Teilobjekte der gesamten Szene bezeichnet werden.
Der erste Sohnknoten der LyberWorld-Wurzel ist ein Ereignisknoten, mit dem die
Zuordnung der Callbackfunktionen zu den verschiedenen Ereignissen realisiert
werden kann. Die IRIS-Inventor-Klasse, welche den Typ des Ereignisknoten definiert,
stellt Methoden zum Anmelden der Callbackfunktionen zur Verfügung.
149

Um zum Beispiel die Callbackfunktion LW_KeyboardEventCallback() so anzumelden,
daß sie bei einem Tastaturereignis (KeyboardEvent) aufgerufen wird, muß die
folgende Methode ausgeführt werden:
addEventCallback( SoKeyboardEvent::getClassTypeId(),
LW_KeyboardEventCallback, NULL )
Die drei weiteren Sohnknoten Baumwurzel, Kugelwurzel und Raumwurzel sind die
Wurzelknoten der einzelnen Interaktionswerkzeuge. Für jeden der Wurzelknoten
sind zwei Teilszenengraphen vorgesehen, die wahlweise in den Gesamtszenengraphen
eingehängt werden können. Die beiden Teilszenengraphen beschreiben jeweils
das Interaktionswerkzeug und sein 3D-Icon.
Abhängig vom aktuellen Systemzustand kann zwischen Werkzeug und 3D-Icon gewechselt
werden. Der in Abbildung 4.14. dargestellte Szenengraph beschreibt folglich
die Visualisierung des Systems im Zustand TreeActive.
5.2.2.1. Der Szenengraph des Kontextbaums
Der Szenengraph des LyberTree-Werkzeuges setzt sich aus den Teilszenengraphen
zusammen, die durch die Konstruktoren der Visualisierungsklassen angelegt werden.
Abbildung 4.15. zeigt den Szenengraphen eines Kontextbaums, der aus drei Ringebenen
besteht.
Der Knoten Baumwurzel hat als Kinder die jeweiligen Wurzelknoten der 3D-Iconbeschreibung
(Icongruppe) und des aktivierten Kontextbaumwerkzeuges (Werkzeuggruppe).
Direkt unterhalb des Werkzeug-Gruppenknotens liegt die Beschreibung
der Visualisierung des Startbegriffs.
An den Szenengraphen des Startbegriffs wird der Szenengraph des durch Expansion
des Begriffs generierten Dokumentenring angehängt. Dieser besteht aus einer Beschreibung
des aktuellen Rotationswinkels durch einen Rotationsknoten und des
Begriffskonuses durch einen weiteren Teilszenengraphen.
Rechts neben der Konusbeschreibung liegen die Symbolbeschreibungen der Ebenenelemente,
im Falle eines Dokumentenrings sind dies Dokumentensymbolbeschreibungen.
Wenn eines der Dokumente des Rings expandiert wird, so wird im Szenengraphen
an die entsprechende Symbolbeschreibung eine neue Ringbeschreibung angehängt.
In unserem Beispielszenengraphen sind zwei Dokumente der ersten Kegelbaumebene,
d.h. des ersten Dokumentrings, expandiert. Folglich hängen an zwei der Dokumentsymbolbeschreibungen
Beschreibungen eines Begriffsringes. In diesen Begriffsringen
der zweiten Kegelbaumebene ist wiederum jeweils ein Begriff
expandiert. Die dritte Ebene des beschriebenen Kontextbaums besteht daher aus
zwei Dokumentringen.
150

Baumwurzel
D
B
Teilszenengraph eines Dokumentenblättchens
Teilszenengraph eines Begriffsblättchens
Icongruppe
Werkzeuggruppe
Szenengraph
des LyberTree-
Icons
material transformation
B
Startbegriff
Dokumentenring 1.Ebene
rotation
cone
D D D D D
Begriffsring 2.Ebene
Begriffsring 2.Ebene
B B B B
Dokumentenring 3.Ebene
Dokumentenring 3.Ebene
D D D D
Abbildung: 4.15.
Der Szenengraph des LyberTree-Werkzeuges
5.2.2.2. Der Szenengraph der Relevanzkugel
Die Teilszenengraphen der graphischen Objekte, aus welchen das LyberSphere-
Werkzeug besteht, werden analog zum LyberTree-Werkzeug durch die Konstruktoren
der Visualisierungsklassen angelegt. Der Gesamtszenengraph der Relevanzkugelvisualisierung
setzt sich aus diesen Teilszenengraphen zusammen.
In Abbildung 4.16. ist der Szenengraph einer Relevanzkugel dargestellt.
Unterhalb des Knotens Kugelwurzel liegen wiederum die Wurzelknoten der
3D-Iconbeschreibung (Icongruppe) und des aktivierten Relevanzkugelwerkzeuges
(Werkzeuggruppe).
151

Kugelwurzel
R
Teilszenengraph eines Referenzpunktsymbols
Icongruppe
Werkzeuggruppe
Szenengraph
Gruppe der
Dokumentenmenge
Gruppe der
Referenzpunktmenge
rotation
Kugelgruppe
des LyberSphere-Icons
rotation
R
rotation
R
rotation
R
Szenengraph
der Kugeloberflächenbe-
schreibung
transformation transformation transformation
O
Dokumentensymbol:
offenes Buch
G
Dokumentensymbol:
geschlossenes Buch
Abbildung: 4.16.
Der Szenengraph des LyberSphere-Werkzeuges
Der erste Sohn des Werkzeuggruppenknotens ist der Wurzelknoten der Dokumentensymbolmenge,
d.h. die Wurzel des Teilszenengraphen, welcher die Beschreibung
der Dokumentensymbole enthält. Jedes Dokumentensymbol wird durch einen
Transformationsknoten, der die Position des Symbols bestimmt und einen Gruppenknoten,
der als Nachfolger entweder den Teilszenengraphen eines offenen oder
den eines geschlossenen Buchs enthält, beschrieben.
Da Knoten im Szenengraphen mehrere Vorgänger haben dürfen, müssen die Teilszenengraphen
zur Beschreibung der zwei verschiedenen Buchsymbole jeweils nur einmal
angelegt werden.
Neben dem Wurzelknoten der Dokumentenmenge liegt der Wurzelknoten der Referenzpunktsymbolmenge.
Die Position der Referenzpunktsymbole wird durch eine
152

Rotation auf der Kugeloberfläche und somit durch einen Rotationsknoten beschrieben.
Da die Beschreibung der einzelnen Referenzpunktsymbole durch Benutzeraktionen
geändert werden kann und die Symbole folglich unterschiedliche graphische Attribute
haben können, muß für jeden Referenzpunkt der symbolbeschreibende Teilszenengraph
neu angelegt werden.
Der letzte Teilszenengraph der Referenzkugelbeschreibung dient zur Festlegung der
Oberflächenbeschaffenheit der Kugel. In Abbildung 4.16. ist der Wurzelknoten dieses
Szenengraphen mit Kugelgruppe bezeichnet. Der Szenengraph wird vom Konstruktor
der oben beschriebenen Klasse ViewSphere angelegt und soll hier nicht näher
erläutert werden.
5.3. Erweiterungsmöglichkeiten
5.3.1. Praktischer Einsatz
Mit INQUERY verfügt der Prototyp über ein Retrieval System, dessen Stärken in
der Verarbeitung wenig strukturierter Volltextdatenbanken liegen. Durch den automatischen
Parser-Prozeß ist es möglich, das Inhaltsnetz ohne menschliches Zutun
zu generieren.
Ein möglicher praktischer Einsatz des LyberWorld-Prototypen sollte bei Datenbanken
mit diesen Eigenschaften liegen. Als konkrete Beispiele lassen sich Zeitungsarchive
oder die Newsgruppen des Usenets nennen. Die Information, die in den Ausgaben
einer Tageszeitung enthalten ist, ist nicht stark strukturiert. Artikel bestehen
im allgemeinen aus Text und Titel. Zusätzliche Informationen wie Autor, Rubrik,
Erscheinungsdatum haben für eine Suche eher nachgeordnete oder eingrenzende
Bedeutung. Verweise auf verwandte Artikel existieren nur in Ausnahmefällen. Eine
Recherche nach Artikeln, die ein bestimmtes Themengebiet betreffen, ist ohne Retrievalsystem
undenkbar.
Ähnliches trifft bei Veröffentlichungen in den Newsgruppen zu. Täglich erscheint
eine große Menge von Artikeln, deren jeweilige Diskussionsthemen und Inhalte sich
dynamisch entwickeln. Eine manuelle Erfassung und Klassifizierung ist durch die
große Informationsmenge und deren unberechenbare Entwicklung wirtschaftlich
nicht vertretbar. Andererseits stellen sie Foren dar, in die die Kompetenz vieler
Fachleute und große praktische Erfahrung einfließen.
Eine Anbindung des Prototypen erfordert lediglich eine Anpassung der INQUERY-
Parser an spezielle Gegebenheiten des Datenmaterials. Artikel der Newsgruppen,
153

die Antworten auf vorhergehende Artikel geben, inkludieren diesen häufig. Diese
Inklusionen sollten entfernt und durch Verweise ersetzt werden. Innerhalb von LyberWorld
sind keine substantiellen Änderungen nötig.
5.3.2. Weitere Datenbanken
Im Laufe der weltweiten Vernetzung der Computer ist der Zugriff auf viele Datenbanken
von einem einzelnen Arbeitsplatz aus möglich. Durch Integration verschiedener
Datenbanken in eine konsistente, fertig konfigurierte Arbeitsumgebung wird
der Bedienungskomfort erhöht.
Dem Benutzer kann der Zugriff auf verschiedene Datenbanken durch eine Erweiterung
der Dokumentenraummetapher ermöglicht werden. Mehrere Datenbanken
können innerhalb der LyberWorld-Umgebung durch mehrere Dokumentenräume
repräsentiert werden. Analog zum jeweils aktuellen Ring, Element und Suchwort
kann eine aktuelle Datenbank in Form eines hervorgehobenen Dokumentenraumicons
eingeführt werden.
5.3.3. Weitere Ein- und Ausgabegeräte
Beim Entwurf des Prototypen ist der Neu- und Weiterentwicklung von Ein- und
Ausgabegeräten Rechnung getragen worden. Innerhalb des Prototypen werden logische
Interaktionen verarbeitet, die durch Treibermodule für das jeweilige Eingabegerät
ausgelöst werden. Für neue Eingabegeräte ist aus diesem Grund lediglich ein
Treiber zu implementieren, der einer Eingabeaktion des Gerätes die gewünschte logische
Aktion zuordnet.
Bei einer Anbindung des Datenhandschuhs müßte das zu implementierende Treibermodul
Gesten definieren und erkennen, die den Aktionen Rotieren, Expandieren,
Schieben usw. intuitiv entsprechen.
Die Einbindung neuartiger Ausgabegeräte wie Crystal Eyes oder Eye Phones ist
durch die Verwendung des Visualisierungswerkzeugs Inventor einfach möglich.
Ohne den Prototypen modifizieren zu müssen, kann durch Auswahl und Konfiguration
des verwendeten Renderes eine stereoskopische Darstellung genauso einfach
eingestellt werden, wie eine Druckausgabe des Szenengraphen.
5.3.4. Konfigurierbarkeit
Das Erscheinungsbild des Prototypen sollte so weit möglich individuell an die Bedürfnisse
des Benutzers anpaßbar sein. Der Prototyp sollte um ein Werkzeug erwei-
154

tert werden, mit dem Systemparameter wie Fenstergröße, Farben, Zeichensätze, Beschriftungen,
Tastaturbelegung, Animationsgeschwindigkeit und ähnliches
interaktiv eingestellt werden können.
5.3.5. LyberInfostore
Im Laufe der Arbeit mit den Werkzeugen Kontextbaum und Relevanzkugel tritt oftmals
das Bedürfnis auf, einen erreichten Dialogzustand abzuspeichern um später die
Arbeit an einem gewünschten Punkt fortzusetzen. Weiter kann dem Benutzer die
Möglichkeit gegeben werden, einzelne Dokumente oder auch ganze Gruppen von
Dokumenten zu späteren Sichtung ’zur Seite zu legen’.
Der Prototyp sollte um eine Metapher erweitert werden, die das Speichern von Objekten
ermöglicht. Denkbar ist ein Schrank mit verschiedenen Schubladen, in denen
die verschiedenen Objekte aufbewahrt werden können.
Folgende Objekte sollten speicherbar sein:
Datenbank
Die Speicheraktion wird auf den Dokumentenraum angewendet.
Suchdialog
Die Speicheraktion wird auf den Kontextbaum angewendet.
Themensegmentierung
Die Speicheraktion wird auf die Relevanzkugel angewendet
Dokumente
Die Speicheraktion wird auf ein oder mehrere Dokumente
angewendet.
Konfiguration
Die Speicheraktion wird auf das Konfigurationswerkzeug
angewendet.
5.3.6. Ein besserer LyberRoom
Nach einer erfolgreichen Anwendung der Werkzeuge des Prototypen sollte der Benutzer
einige interessante Dokumente der Datenbank gefunden haben. Diese will
der Benutzer möglicherweise nicht nur lesen oder sichten, sondern nach eigener
Maßgabe weiterverarbeiten. Innerhalb des Dokumentenraums sollten Methoden zur
Verfügung stehen, die Dokumente ausdrucken und sie als Textdatei abspeichern.
155

Bei der Anzeige eines Dokuments innerhalb des LyberRoom wäre es weiter wünschenswert,
wenn die vom Retrievalsystem als relevant eingestuften Begriffe hervorgehoben
dargestellt wären. Der Benutzer könnte so eventuellen Fehleinschätzungen
auf die Spur kommen oder, falls Baum oder Kugel aktiviert sind, durch
Selektion eines Begriffs dessen Hinzufügung in das aktivierte Werkzeug auslösen.
Da der Dokumentenraum als Metapher für die gesamte Datenbank steht, sollte er die
Möglichkeit bieten, Statusinformationen der Datenbank abzurufen. Dazu könnten
der Name der Datenbank, Zugriffskosten, technische Informationen, Umfang des
Inhaltsraums, Umfang der Kontextmenge und ähnliches gehören.
156

6. Bibliographie
[AKEL89]
The Silicon Graphics 4D/240GTX Superworkstation
K. Akeley
IEEE Computer Graphics and Applications 9(4) July 1989, 71–83
[BELKIN92] Information filtering and information retrieval: Two sides of the same
coin?
Nicholas J. Belkin, W. Briuce Croft
Communications of the ACM, December 1992, Vol 35, No. 12
[BORD93]
A dynamic Gesture Language and Graphical Feedback for Interaction
in a
3D User Interface
M. Bordegoni, M. Hemmje
EUROGRAPHICS ’93 Conference Issue, September 1993
[BRON]
Taschenbuch der Mathematik
Bronstein, Semendjajew
Verlag Harri Deutsch
Thun und Frankfurt/Main
[CACM84]
An Interview with Andries van Dam
Communications of the ACM 27(7), August 1984
[CHAR91]
Baysian Networks without Tears
Eugene Charniak
AI Magazine, 14(4), Winter 1991
[CROFT91]
Evaluation of an Inference Network–Based Retrieval Model
Howard Turtle, W. Bruce Croft
ACM Transactions on Information Systems, Vol 9, No. 3, July 1991,
Seite 187–222
[CROFT92]
The INQUERY Retrieval System
James. P. Callan, W. Bruce Croft, Stephen M. Harding
Proceedings of the Third International Conference on Database
and Expert Systems, September 1992
157

[ENC88]
Computer Graphics
J. Encarnaçao, W.Straßer
3. Auflage, Oldenbourg, 1988
[ENDN89]
Endnutzer und Voltextdatenbanken
U. Riehm, K. Böhle, B. Wingert, I. Gabel–Becker, M. Loeben
Kernforschungszentrum Karlsruhe, 1989
[FELGER92] How interaktive visualisation can benefit from multidimensional input
devices
W. Felger
Visual Data Interpretation, Proc. SPIE 1668, 1992
[FOLEY90]
Computer Graphics – Principles and Practice
Foley, van Dam, Feiner, Hughes
Second Edition, Addison Wesley, 1990
[HEMMJE]
Expeditionen in Informationsräume: Zur Konzeption eines graphischen
Informationssystems auf der Basis dreidimensionaler Visualisierungen
M. Hemmje, H.-D. Boecker, U. Thiel
ISI ’92 Proc. of 3rd International Symposium for Information Science,
Saarbrücken, November 1992
[HEMMJE92] Eine inhaltsorientierte, intuitive 3D–Benutzerschnittstelle für
Information–Retrieval– Systeme
Matthias Hemmje
Gesellschaft für Mathematik und Datenverarbeitung, 1991
[INVEN92]
IRIS Inventor Programming Guide. Volume I: Using the Toolkit
Silicon Graphics Computer Systems, SGI, 1992
[KORF91]
Too see or not to see: Is that the query?
R.R. Korfhage
Proceedings of SIGIR ’91, Chicago, pp. 134–141, ACM press, 1991
[LARKIN87] Why a Diagram is (Sometimes) Worth Ten Thousend Words
J.H. Larkin, H.A. Simon
Cognitive Science 11, 1987
158

[LEX79]
[MACH78]
[MAU89]
[OLSEN91]
[PARC]
[ROB91]
Lex, a lexikal analyzer generator
M. E. Lesk und E. Schmitt
In UNIX Programmers Manual, Bell Telephone Laboratories Inc.
Murray Hill, New York, 1979
A Brief Personal History of Computer Graphics
C. Machover
Computer 11(11), November 1978, 38–45
M. L. Mauldin
Information retrieval by text skimming
PhD. theses, School of Computer Science
Carnegie Mellon University, Pittsburg, PA, 1989
Visualisation of a document collection: The VIBE System.
K.A. Olsen, R.R. Korfhage
Report LIS033/IS91001, School of Libary and Information Science,
University of Pittsburgh, 1991
The Information Visualizer, an Information Workspace
Stuart K. Card, George G. Robertson, Jock D. Mackinlay
Xerox Palo Alto Research Center
In: SIGCHI ’91 Conference Proceedings, pp 181–198, ACM press,
1991
Cone Trees: Animated 3D Visualizations of Hierachical Information
George G. Robinson, Jock D. Mackinlay, Stuart K. Card
Xerox Palo Alto Research Center
In: SIGCHI ’91 Conference Proceedings, pp 189–194, ACM press,
1991
[SILICON91] Graphics Libary Programming Guide
Silicon Graphics Computer Systems, SGI, 1991
[SPACE91]
[STRAU92]
Spaceball
Spaceball Technologies Inc. 1991
An Objekt–Oriented 3D Graphics Toolkit
P.S. Strauss, R.Carey
Computer Graphics (SIGGRAPH’92 Proceedings) 26(2) S.341–347,
1992
159

[SUTH63]
Sketchpad: A Man–Machine Graphikal Communication System
I.E. Sutherland
Proceedings of the Spring Joint Computer Conference, Baltimore,
1963
160

161

162

163

164

165

166

167

168

169