Anhang A
Konvertier-Programm für Thesaurus-Daten

Wolfram R. Sieber

Der Inhalt dieser Seite bildete ursprünglich den Anhang A meiner Diplomarbeit, Visualisierung von Thesaurus-Strukturen unter besonderer Berücksichtigung eines Hyperbolic Tree Views. Die Arbeit entstand im Sommer 2004 am Institut für Informationswissenschaft der Fachhochschule Köln.

Professor Dr. Klaus Lepsky danke ich ganz herzlich dafür, dass er den Webspace für diese Seite sowie den Quelltext des hier entwickelten Thesaurus-Konvertier-Tools (freigegeben unter der GNU Lesser General Public License) zur Verfügung stellt. Außerdem stellt er eine mth-Beispieldatei bereit, für die der hier vorgestellte Konvertierer entwickelt wurde.

 

Ausgangssituation

Bestandsaufnahme

Am Anfang dieser Arbeit stand neben anderen die Frage, wie sehr sich Munzners H3 dazu eignet, Thesaurus-Strukturen zu visualisieren. Als Beispiel-Thesaurus dient ein Auszug aus dem Infodata-Thesaurus1. Dieser liegt als Textdatei in einem bestimmten Format vor. Munzners H3 verwendet als Eingabe ebenfalls eine Textdatei. Diesen Visualisierer in die Untersuchung in Kapitel 4 einzubeziehen, setzte daher voraus, dass die Thesaurus-Datei dergestalt umgewandelt wurde, dass sie dem H3-Eingabeformat entsprach.

Vereinbarungen bezüglich einzelner Begriffe

Das Format der Thesaurus-Datei wird in das Format derjenigen Datei gewandelt, das als Eingabe für H3 dient. Auf dieser Basis visualisiert H3 den Thesaurus. Letzteres bildet das Eingabeformat für H3, aber das Ausgabeformat des Konvertierprogrammes. Eingabeformat des Konvertierprogrammes hingegen ist das der Thesaurus-Datei. Um Verwechslungen zu vermeiden, bestehe im Folgenden bei Ein-, Ausgaben, Dateien und Formaten jeweils der implizite Bezug zu dem Konvertierprogramm, so dass Eingabe implizit die Eingabe für das Konvertierprogramm meine, ebenso wie Ausgabe die desselben. Abweichungen von dieser Konvention werden explizit gekennzeichnet. Das Konvertierprogramm selbst wird als T2H32 bezeichnet.

Formate

Eingabeformat: Thesaurus-Format

Die Eingabe für den Konvertierer bildet eine Textdatei, die einen Thesaurus definiert. Nacheinander werden dort Deskriptordatensätze definiert. Voneinander getrennt werden sie jeweils durch eine Zeile, die aus nichts anderem als der Zeichenfolge &&& besteht, an die sich eine oder mehrere Leerzeilen anschließen. Jeder Deskriptordatensatz ist mehrere Zeilen lang. Jede dieser Zeilen bildet ein Datenfeld, das in Feldkennung und Feldinhalt oder Wert(e) unterteilt ist. Die Kennung besteht aus zwei Zeichen, die in den meisten Fällen durch einen Doppelpunkt von dem Rest der Zeile separiert ist.3 Der Wert ist eine Zeichenkette, die sich bis zum Ende der Zeile erstreckt. Übliche Kennungen sind DE, SY, BT, NT und RT. Daneben gibt es noch weitere Kennungen, die für die Konvertierung aber ohne Belang sind. Die genannten Kennungen stehen für Vorzugsbezeichnung (DE), Nicht-Vorzugsbezeichnung (SY), Oberbegriff (BT), Unterbegriff (NT) und verwandter Begriff (RT). Während ein Deskriptordatensatz jeweils nur eine Vorzugsbezeichnung aufweist, sind als Nicht-Vorzugsbezeichnungen mehrere Werte möglich: Soll ein Datenfeld mehr als einen Wert repräsentieren, so werden alle Werte nacheinander in derselben Zeichenkette angegeben, durch Leitung-Symbole (engl. Pipe; ”|”) voneinander getrennt. Abbildung 1.1 zeigt einen Auszug aus der verwendeten Eingabedatei.



Abbildung 1.1: Eingabeformat für das Konvertierprogramm

DE:Änderung 
SY:Veränderung 
RT:Korrektur|Pflege|Umstellung 
L1:Change 
&&&

DE:Alphabetische Katalogisierung 
ER:bis Febr. 83 benutzt: Katalogisierung 
BE:nach bibliothekarischen Regeln 
BT:Katalogisierung 
SY:Bibliographische Beschreibung|Formalkatalogisierung 
RT:Alphabetischer Katalog|Formale Erfassung|[...]|Sachkatalogisierung 
&&&


Ausgabeformat: H3-Format

Das Konvertierprogramm gibt eine Datei aus, die H3 als Eingabe dient. Diese Datei ist zeilenweise strukturiert. Jede Zeile definiert einen einzelnen Knoten. Gleichzeitig definiert die Reihenfolge, in der solche Knoten-Definitionen aufeinanderfolgen, Kanten zwischen den jeweiligen Knoten. Vier Angaben bilden eine Knoten-Definition: eine Tiefenkennung, die Bezeichnung eines Knotens, eine Gruppenkennung sowie eine Typkennung. Diese vier Angaben sind jeweils durch Leerraum (Leerzeichen und/oder Tabulator-Zeichen) voneinander getrennt. Mehrere verschiedene Typkennungen sind vordefiniert, u.a. audio, image, host, html und text.4 Jede dieser Kennungen steht für eine bestimmte Farbe, in der ein Knoten dargestellt wird. Entsprechend kann diese Kennung synonym als Farbkennung bezeichnet werden. Die Gruppenkennung kann dazu verwendet werden, zu forcieren, dass bestimmte Knoten zu Gruppen zusammengefasst und deswegen unmittelbar benachbart dargestellt werden.5 Die Knoten-Bezeichnung darf weder Leerräume noch Umlaute oder ß-Zeichen enthalten.6 Die Tiefenkennung ist für das Definieren von Kanten relevant: Knoten B1 .. Bn, die einem anderen Knoten A untergeordnet sein sollen, werden durch eine Tiefenkennung gekennzeichnet, die um eins7 größer ist als die von A. Abbildung 1.2 zeigt einige Beispiele für Knoten- und Kanten-Definitionen.



Abbildung 1.2: Eingabeformat für H3 / Ausgabeformat des Konvertierprogramms

0 *world* 1 audio 
... 
1 Aenderung 1 text 
2 Veraenderung 1 host 
2 Umstellung 1 text 
2 Korrektur 1 text 
2 Pflege 1 text 
... 
1 Katalogisierung 1 text 
... 
2 Alphabetische_Katalogisierung 1 text 
3 Bibliographische_Beschreibung 1 host 
3 Formalkatalogisierung 1 host 
...


Weist ein Bxdieser B-Knoten seinerseits Kinder C1 .. Cm auf, so dass Bx einen Zweig oder Ast des Baumes bildet, so muss zunächst der gesamte C-Zweig/-Ast definiert werden, ehe mit dem nächsten B-Knoten (Bx+1) fortgefahren werden kann. Der zuletzt definierte Knoten eines C-Zweiges/-Astes weist inhärent eine Tiefenkennung auf, die größer der von Bx ist. Um daran anschließend eine Kante von A nach Bx+1 zu definieren, erhält Bx+1 (genauso wie B1 .. Bx) die Tiefenkennung von A plus eins. Dies führt dazu, dass H3 keine Kante zwischen dem letzten unterhalb von Cm definierten Knoten und Bx+1 anlegt, sondern eine zwischen A und Bx+1.

Kinder desselben Elter-Knotens weisen demzufolge allesamt die Tiefe des Elters plus eins auf, doch impliziert dies, dass weder Kinder, die mehr als eine Ebene von ihrem Eltern entfernt liegen, definiert werden können noch Kanten zwischen Geschwister-Knoten. Dies wiederum impliziert, dass Kanten zwischen solchen verwandten Begriffen, die Kinder derselben Eltern sind, nicht adäquat wiedergegeben werden können, sondern in verschiedene Ebenen platziert werden müssen.

Verwandte Begriffe bewirken dadurch implizit eine Polyhierarchie. Damit ist hier ein Knoten B gemeint, dem mehrere Knoten A1 .. Ao übergeordnet sind: z.B. mehrere Oberbegriffe oder ein Oberbegriff und ein verwandter Begriff, etwa Ay und Az(bei {Ay, Az}Í{A1 .. Ao}). Im Eingabeformat für H3 kann eine Polyhierarchie dadurch abgebildet werden, dass zunächst Ay definiert wird, anschließend Az, dann B und schließlich ein Rückbezug von B zu Ay. Dieser Rückbezug wird dadurch hergestellt, dass im Anschluß an B der Knoten Ay erneut definiert wird, jedoch mit der Tiefenkennung von B plus eins.8

Konvertierung

Zielsetzung

Das Konvertierprogramm soll die Thesaurus-Definition dergestalt in H3-Eingabedaten wandeln, dass Elemente gleicher Art - etwa Vorzugs- und Nicht-Vorzugsbezeichnungen - stets dieselben Farben erhalten. Die Oben—Unten-Orientierung der Darstellung soll erkennbar sein.9 Dazu sollen Unterbegriffe unterhalb von Oberbegriffen angeordnet werden und Nicht-Vorzugsbezeichnungen unterhalb ihrer jeweiligen Vorzugsbezeichnungen. Besondere Relationen - wie z.B. Begriffsverwandtschaften - sollen deutlich erkennbar sein. Fehler in den Thesaurus-Strukturen sollen geradezu ins Auge springen,10 während eventuell durch den Konvertierer hinzugefügte Hilfsknoten möglichst unscheinbar wirken sollen.

Schwierigkeiten

Bei Polyhierarchien in einem Thesaurus befinden sich die Elternknoten eines Kind-Knotens nicht zwangsläufig in der unmittelbar darüberliegenden Ebene, sondern können auch auf verschiedenen Ebenen liegen. Auch können verwandte Begriffe verschieden tief im Thesaurus liegen. Für den tiefer liegenden der beiden verwandten Begriffe bildet diese Relation dadurch eine Polyhierarchie. Wie dergleichen Polyhierarchien für das H3-Eingabeformat aufbereitet werden müssen, wurde bereits auf der vorherigen Seite dargestellt.

Die eigentliche Schwierigkeit bei der Konvertierung besteht darin, Polyhierarchien mittels des Eingabeformates von H3 korrekt zu definieren: Untergeordnete Knoten (Unterbegriffe, Nicht-Vorzugsbezeichnungen) sollen stets unterhalb der ihnen übergeordneten Knoten (Oberbegriffe, Vorzugsbezeichnungen) ausgegeben werden. Daher dürfen die Kanten von Polyhierarchien erst dann definiert werden, wenn bereits alle an der Polyhierarchie beteiligten Knoten11 definiert sind. Dies gilt nicht nur für Oberbegriff—Unterbegriff-Relationen, sondern auch für Relationen zwischen verwandten Begriffen, die verschieden tief liegen.

Neben der Schwierigkeit, Polyhierarchien korrekt auszugeben, besteht die Problematik, dass die Eingabedatei - der gewählte Thesaurus - Schwächen aufweist: So werden teilweise Vorzugsbezeichnungen von Deskriptoren als Nicht-Vorzugsbezeichnungen anderer Deskriptoren ausgewiesen, Benennungen werden uneinheitlich groß, klein, getrennt oder zusammen geschrieben oder auf andere Weise uneinheitlich dargestellt, Deskriptoren können mittel- oder unmittelbar als ihre eigenen Kinder definiert sein, zu zahlreichen Deskriptoren werden verwandte Begriffe ausgewiesen, die innerhalb der Hierarchie gar nicht definiert sind. Solche Begriffe sind ausschließlich dadurch als Deskriptoren zu erkennen, dass sie als zu anderen Deskriptoren verwandt ausgewiesen sind; doch werden sie nirgends als Ober- oder Unterbegriffe anderer Deskriptoren angegeben.

Lösungen

Mängel im Thesaurus werden ermittelt und gemeldet, ehe die Konvertierung beginnt. Die Aufgabe und Leistung der Konvertierung besteht darin, die Knoten, Kanten und insbesondere die Polyhierarchien in einer korrekten Reihenfolge auszugeben. Weil H3 nur genau einen obersten Knoten zulässt, wird als Wurzel statt des Top Terms ein Hilfsknoten *world* verwendet, dem all jene Deskriptoren unmittelbar untergeordnet werden, die ausschließlich durch ihre Verwandtschaft zu anderen Deskriptoren definiert sind.

Ein möglich erscheinender Ansatz für die Konvertierung ist, die Begriffsleitern schlicht von oben nach unten auszugeben. Doch dieser Ansatz scheitert bereits an Unterbegriffen, die mehr als einen Oberbegriff aufweisen: Solche Unterbegriffe würden in diesem Fall mehrfach ausgegeben. H3 untersucht seine Eingabedaten aber nicht auf Dubletten, so dass ein Bereich, der sich unterhalb solcher polyhierarchischen Unterbegriffe befindet, schlicht mehrfach in der Visualisierung erscheinen würde.

Der alternative Ansatz, Begriffsleitern wie oben dargestellt auszugeben, aber bei Polyhierarchien zusätzlich zu den Unterbegriffen die beteiligten Oberbegriffe zu definieren, schlägt ebenfalls fehl: Angenommen, die Tiefenkennung des Unterbegriffes ist T. Würde für die Oberbegriffe daher eine Tiefenkennung von T - 1 angenommen, so würden sie für H3 als ”Tanten”/”Onkel” des fraglichen Unterbegriffes angelegt. - Im Thesaurus sind sie aber möglicherweise an ganz anderer Stelle/in ganz anderer Ebene lokalisiert. Würde also für die Oberbegriffe eine Tiefenkennung von T - 1 verwendet, so bestünde die Möglichkeit, dass diese Oberbegriffe an falscher Stelle platziert würden. - Eine Tiefenkennung von T für diese Oberbegriffe ist offensichtlich ungültig, denn dadurch würden sie auf derselben Ebene platziert wie der fragliche Unterbegriff. Dies stünde aber im Widerspruch zu der Eingangsbedingung, dass Oberbegriffe stets mindestens eine Ebene oberhalb ihrer Unterbegriffe liegen sollen. Alternativ die Tiefe von T + 1 für die Oberbegriffe zu verwenden, widerspricht diesem Kriterium ebenfalls, da die Oberbegriffe dadurch sogar unterhalb ihrer Unterbegriffe angeordnet würden. Also führt auch dieser Ansatz nicht zum Ziel.

Zum Ziel führt dagegen, untergeordnete Knoten U einer Polyhierarchie im Anschluss an den tiefsten Knoten Ox auszugeben, der U unmittelbar übergeordnet ist, und anschließend ausgehend von U die Rückbezüge zu O1 .. On\Ox herzustellen. Rückbezüge können aber erst dann hergestellt werden, wenn alle Oy{O1 .. On\Ox} bereits ausgegeben sind, zu denen diese Rückbezüge hergestellt werden sollen. Infolgedessen darf auch Ox - sogar: der ganze Zweig, zu dem Ox gehört, - erst dann ausgegeben werden, wenn alle Oy bereits ausgegeben sind: Der Zweig, der Ox umfasst, muss (in Bezug auf die Ausgabe dieser Polyhierarchie) als letzter ausgegeben werden.

Bei der Konvertierung werden daher die Tiefen sämtlicher Knoten ermittelt. Anzulegende Kanten werden intern abgebildet, Polyhierarchien detektiert. Kanten zwischen Knoten werden jeweils bei beiden beteiligten Knoten vermerkt. Bei Polyhierarchien werden diese Vermerke jedoch anschließend bei fast allen O-Knoten gelöscht: Lediglich bei dem (ersten) O-Knoten mit der größten Tiefe bleibt dieser Vermerk erhalten; der U-Knoten erhält die Tiefe dieses tiefsten O-Knotens plus eins. - Während die Vermerke bei allen bis auf einen O-Knoten gelöscht sind, bleiben im U-Knoten sämtliche dieser Vermerke erhalten: Sie werden bei der Ausgabe verwendet, um die Rückbezüge herzustellen. Anschließend erfolgt die Ausgabe dieses intern abgebildeten Netzes. Indem vermerkt wird, welche Knoten/Zweige/Äste bereits ausgegeben worden sind, wird sichergestellt, dass der Ox-Zweig einer Polyhierarchie jeweils zuletzt ausgegeben wird.

Das Vorgehen im Einzelnen

Die Umwandlung erfolgt als Sequenz: Vorverarbeiten — Analysieren und intern Repräsentieren — Ausgeben. Die Vorverarbeitung besteht darin, die Datei einzulesen und als günstig weiterverarbeitbare Datenstrukturen bereitzustellen. In Deskriptorzeilen_ermitteln()1213 wird die Datei in ein Array eingelesen, das je Zelle einen ganzen Datensatz enthält. Daran anschließend ermittelt Datensaetze_ermitteln()14 die Datenfelder jedes einzelnen Datensatzes und bildet sie in jeweils ein Hash ab: Feldkennungen bilden die Schlüssel des Hashes, Feldinhalte die Werte. Die Hashes werden wiederum (als Referenzen) in einem Array abgelegt. Dadurch wird gewährleistet, dass ein Zugriff auf ein Feld des Arrays zu einem Datensatz führt und jeder einzelne Feldinhalt mittels seiner Feldkennung erreichbar ist.

In einem dritten Schritt analysiert Struktur_aufbauen()15 die Datensätze und baut die durch die Eingabedatei definierte Struktur intern auf. Dabei werden auch Fehler in den Definitionen bemerkt, die der Vorverarbeitung verborgen bleiben, zum Beispiel Schleifen, in denen ein Deskriptor indirekt sein eigenes Elter ist. Die Routine verwendet alle_Knoten_ermitteln()16 Datensatz_verarbeiten()17 um auch jeden einzelnen Wert eines Datensatzes unmittelbar zugreifbar zu machen. Mittels alle_Knoten_ermitteln() werden alle anzulegenden Knoten ermittelt - inkl. der für Nicht-Vorzugsbezeichnungen.

Durch Referenzen werden Vorzugsbezeichnungen miteinander verbunden, sowie mit ihren jeweiligen Nicht-Vorzugsbezeichnungen. Explizit wird die Menge der Top Terms ermittelt. Enthält diese Menge mehr als ein Element, so wird ein Hilfsknoten *world* hinzugefügt, der als Elter aller Top Terms fungiert. Anschließend stellt Tiefen_ermitteln()18 fest, wie viele Grade jeder Knoten von der Wurzel des Thesaurus19 entfernt liegt, d.h. die Tiefe jedes Knotens. Als Tiefe eines untergeordneten Knotens20 wird die Gradzahl des tiefsten übergeordneten Knotens plus eins vermerkt.

Nachdem der gesamte Thesaurus im Speicher aufgebaut ist und die Tiefen ermittelt sind, wird die Ausgabe vorbereitet: Ausgabe_vorbereiten()21 verknüpft die Menge der Top Terms mit *world* und bereitet die Ausgabe der unterhalb dieses Knotens liegenden Äste via AstAusgabe_vorbereiten()22 vor. Um Polyhierarchien korrekt ausgeben zu können, stellt diese Routine fest, welcher der tiefste übergeordnete Knoten ist:


... 
380 if (abs ($$ref_node {$__NodeDepth_hash_key} -  
381          $$ref_child {$__NodeDepth_hash_key}) > 1)  
382 { 
   ... 
401 } 
...



Der tiefste übergeordnete Knoten einer Polyhierarchie hat zu dem ihm untergeordneten einen Abstand von genau einem Grad, der Abstand aller übrigen23 ist größer. Damit ausschließlich die Kante zwischen diesen beiden Knoten ausgegeben wird, entfernt AstAusgabe_vorbereiten() die Kanten zwischen dem untergeordneten Knoten und allen übrigen ihm übergeordneten. Dass diese Kanten überhaupt vorhanden waren, wird im Nachbarn-Speicher vermerkt.

Dergestalt vorbereitet wird schließlich die gesamte Struktur ausgegeben: Zunächst die Wurzel, anschließend via Ast_ausgeben()24 rekursiv alle darunter hängenden Äste. Ist einem Knoten ein nicht-leerer Nachbar-Speicher beigefügt, so ist dies ein Indikator dafür, dass der Knoten selbst ein tiefster untergeordneter Knoten einer Polyhierarchie ist. Daher werden, nachdem der Knoten selbst ausgegeben ist, alle Nachbar-Einträge ausgegeben, d.h. die Kanten zu den übrigen ihm übergeordneten Knoten.

Abschlussbemerkungen

Ein Knoten wird abhängig davon, was er repräsentiert - z.B. Vorzugs- oder Nicht-Vorzugsbezeichnung -, eingefärbt. Fehlerfälle erhalten eine möglichst auffällige Farbe, damit sie den Blick auf sich lenken. Der *world*-Knoten wird - weil er irrelevant ist - möglichst unauffällig gefärbt: rot25.

Tiefergehende Details sind im Quelltext dokumentiert.

 


Fußnoten:

1 in der Fassung, wie er dem Institut für Informationswissenschaft (Fakultät für Informations- und Kommunikationswissenschaften) der Fachhochschule Köln vorliegt, vgl. [GLO 2004], S. 1, Abschnitt ”Datenquellen”, Punkt 4

2 kurz für: Thesaurus-To-H3

3 In anderen Fällen erfolgt die Trennung durch ein Leerzeichen.

4 Die Bezeichnungen image, host usw. rühren daher, dass H3 ursprünglich für die Visualisierung der Web-Struktur entwickelt wurde.

5 Von dieser Kennung wurde kein Gebrauch gemacht. Stattdessen wurde sie einheitlich, für sämtliche Zeilen der Ausgabe, auf 1 gesetzt.

6 Enthält sie dennoch Umlaute oder ß, so produziert H3 erhebliche Darstellungsfehler.

7 Ist die Tiefe von Bx um mehr als eins größer als die von A, so ignoriert H3 dies schlicht und nimmt an, dass die Tiefe von Bx um genau eins größer als die von A sei.

8 H3 stellt Kanten stets als einen Farbverlauf von rot nach blau dar. Der rote Anfang einer Kante beginnt stets bei dem in der Definitionsdatei zuerst erscheinenden Knoten. - Bei Polyhierarchien hat dies jedoch die Implikation, dass der Farbverlauf von Ay nach B stets rot—blau ist, während der von Ax nach B stets blau—rot ist: Denn tatsächlich handelt es sich um eine Kante von B nach Ax, die - korrekt - rot—blau gefärbt ist - aber eben nur aus ”Sicht” von B. - Der Farbverlauf einer solchen Kante suggeriert eine Orientierung der Kante: rot oben - blau unten. Diese ist aber, wie soeben gezeigt, ungültig. Daher muss der Farbverlauf der Kanten ignoriert werden.

9 H3 bietet hier eine scheinbare Erleichterung, indem es Kanten ausschließlich als Farbverlauf von rot nach blau anzeigt. Der Farbverlauf richtet sich dabei danach, welcher von zwei Knoten zuerst definiert wird: Wird zunächst ein Knoten A definiert und anschließend ein Knoten B, so befindet sich das rote Ende der Kante bei A, das blaue bei B. Dadurch werden in einem Baum (!) einheitlich alle Kanten mit dem blauen Ende unten und dem roten oben dargestellt. Doch handelt es sich bei einem Thesaurus nicht um einen Baum, sondern um ein Netz: An vielen Stellen ist unumgänglich, Rückbezüge von tiefer gelegenen Knoten zu höher platzierten vorzunehmen. Dadurch wird die durch die Farbverläufe erreichte Oben-Unten-Orientierung beschädigt.

Auch wäre für Kanten zwischen Begriffen, die in nicht-hierarchischer Beziehung zueinander stehen - namentlich: verwandten Begriffen - eine neutrale Farbgebung besser geeignet; doch solchen Kanten einen Farbverlauf zu geben, ist schlicht irreführend. Als einzige Möglichkeit, dieser Situation zu begegnen, bleibt, die Farbverläufe der Kanten zu ignorieren.

10 Ein zu kennzeichnender Fehler liegt etwa dann vor, wenn eine einzige Vorzugsbezeichnung mehreren Nicht-Vorzugsbezeichnungen zugeordnet ist.

11 also z.B. alle Oberbegriffe sowie der gemeinsame Unterbegriff

12 Routine ist im Quelltext ab Zeile 1474 enthalten.

13 [Fußnote gelöscht]

14 Routine ist im Quelltext ab Zeile 1378 enthalten.

15 Routine ist im Quelltext ab Zeile 429 enthalten.

16 Routine ist im Quelltext ab Zeile 729 enthalten.

17 Routine ist im Quelltext ab Zeile 809 enthalten.

18 Routine ist im Quelltext ab Zeile 466 enthalten.

19 d.h.: von dem Hilfsknoten *world* oder dem (einzigen) Top Term

20 d.h. eines Knotens, der einen Unterbegriff oder eine Nicht-Vorzugsbezeichnung repräsentiert

21 Routine ist im Quelltext ab Zeile 301 enthalten.

22 Routine ist im Quelltext ab Zeile 344 enthalten.

23 Ausnahme hiervon bilden die Nachbarn des tiefsten Oberbegriffes. Relationen von diesem zu dem Unterbegriff sind zulässig, da sie auszugeben nicht dazu führen würden, dass H3 den Unterbegriff in geringerer Tiefe als gewünscht anlegt: In solch einem Fall liegen alternative Oberbegriffe und tiefster Oberbegriff in derselben Tiefe. Ergo kann H3 den fraglichen Unterbegriff nicht unbeabsichtigt darüberliegend anordnen.

24 Routine ist im Quelltext ab Zeile 117 enthalten.

25 Rings um die Wurzel zeichnet H3 eine Unzahl rot-blauer Kanten, so dass ein rot gefärbter Knoten dort kaum auffällt.