DE69510962T2

DE69510962T2 - Semantisches netzwerk

Info

Publication number: DE69510962T2
Application number: DE69510962T
Authority: DE
Inventors: Martin Trotter
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1995-06-19
Filing date: 1995-12-01
Publication date: 2000-02-24
Anticipated expiration: 2015-12-02
Also published as: DE69510962D1; GB2302420A; GB9512453D0; EP0834140B1; US5870751A; EP0834140A1; WO1997000486A1

Description

Technisches Gebiet

Die vorliegende Erfindung betrifft das Gebiet der Datenverarbeitung und insbesondere die Darstellung der wechselseitigen Beziehungen zwischen Daten und der Speicherung dieser Daten durch die Verwendung eines semantischen Netzwerks.

Stand der Technik

Konzeptuelles Datenmodellieren wird verwendet, um Beschreibungen von Objekten und ihrem Verhalten in der realen Welt zu erfassen und strukturierte Darstellungen hierfür in einer Datenbank zu finden. Seit den frühen sechziger Jahren wurden viele verschiedene Datenmodelle (Datenbehandlungssprachen) vorgeschlagen. Ein Datenmodell ist ein Werkzeug für das Entwickeln einer Datenbank. Es umfaßt einen Satz Regeln, mit denen die Struktur und die Bedeutung der Daten in der Datenbank sowie die Operationen, die mit den Daten durchgeführt werden können, beschrieben werden.
Klassische für die Datenbankentwicklung verwendete Datenmodelle lassen sich generell einer von drei Kategorien zuordnen: hierarchische, Netzwerk- und relationale Datenmodelle. Beispiele für diese drei Kategorien sind IMS von IBM (hierarchisch), IDS von Honeywell (Netzwerk) und DB2 von IBM (relational). Hierarchische Modelle und Netzwerkmodelle verwenden das Konzept von Datensätzen als eine Sammlung mit Namen versehener Felder, die die einzelnen Datensubjekte darstellen. Das hierarchische Modell erlaubt zusätzlich eine baumartige Anordnung von eins-zu-vielen-Beziehungen, in denen jeder Datensatz auf einer einzigen angegebenen Stufe der Hierarchie vor kommt. Das relationale Modell enthält nur Datensatztypen und keine expliziten Verbindungen zwischen Datensubjekten. Mit allen dreien dieser klassischen Datenmodelle ist es nicht möglich, einen größeren Teil der zu den Daten gehörenden semantischen Daten zu erfassen. Das grundlegende Gedankengebäude, der Datensatz, stellt keine atomare semantische Einheit dar. Es sind zusätzliche Einschränkungen erforderlich, um die semantische Integrität der Datenbank aufrechtzuerhalten und um beispielsweise sicherzustellen, daß ein durch einen Namen gekennzeichnetes identifiziertes Subjekt in einer Beziehung oder in einem Datensatz wirklich in der Datenbank existiert.
Aufgrund der Mängel der klassischen Datenmodelle bei der Verwendung für das konzeptuelle Datenmodellieren wurden viele Vorschläge für semantische Datenmodelle gemacht. Bei semantischen Datenmodellen werden die Informationen in Form atomarer Einheiten modelliert, die als Entitäten oder Objekte bezeichnet werden. Diese können als Dinge definiert werden, die existieren und die voneinander unterschieden werden können, d. h. die Art und der Name sind der Entität bzw. dem Objekt zugeordnet. Beispiele hierfür sind "Mitarbeiter mit dem Namen Peter Müller" oder "Firma mit dem Namen Lebensmittelgenossenschaft". Das Dokument "Object-Oriented Databases - A Semantic Data Model Approach" (Objektorientierte Datenbanken - Ein Ansatz mit einem semantischen Datenmodell), Peter M. D. Gray, Krishnarao G. Kulkarni, Norman W. Paton, veröffentlicht durch Prentice Hall, 1992, beschreibt das konzeptuelle Datenmodellieren, klassische Datenmodelle und ihre Mängel sowie semantische Datenmodelle.
Eines der semantischen Datenmodelle, das für das Modellieren verwendet wurde, ist das Modell eines semantischen Netzwerks. Die grundlegende Struktur eines Modells eines semantischen Netzwerks besteht aus Knoten und Bögen, die ein Netzwerk bilden. Die Knoten stellen Datenelemente oder Subjekte dar, wie Peter Müller oder Lebensmittelgenossenschaft in den Beispielen oben. Die Bögen stellen Beziehungen wie "ist Mitarbeiter von" und "beschäftigt" dar. Die Subjekte weisen häufig zahlreiche zwischen ihnen mögliche Wechselbeziehungen auf, aber nur wenige dieser Beziehungen werden wirklich verfolgt. Das IBM Technical Disclosure Bulletin, Band 34, Nr. 5, Oktober 1991, S. 412, offenbart eine Technik für das Implementieren von "HasMember"- Beziehungen als Einwege-Beziehungen, die sich die Tatsache zunutze macht, daß viele der potentiellen Beziehungen niemals wirklich verfolgt werden, Diese Tatsache wird genutzt, um den benötigten Speicherplatz zu reduzieren.
J. Mylopoulos, P. A. Bernstein und H. K. T. Wong offenbaren in "A language facility for designing database intensive applications" (Eine Spracheinrichtung für das Entwickeln datenbankintensiver Anwendungen), ACM Transactions on Database Systems 5, 185-4307, 1980, die TAXIS-Programmiersprache als ein Beispiel für ein semantisches Netzwerk für die Daten- und Prozedurenmodellierung.
Die britische Patentanmeldung 2187 580 offenbart verknüpfte Seiten dreier Typen, des primären, des sekundären und des tertiären Typs. Primäre Verknüpfungen verknüpfen eine Seite mit einer über- oder untergeordneten Seite auf einer logisch vorangehenden oder nachfolgenden Ebene. Sekundäre Verknüpfungen verknüpfen auf serielle Weise Rahmen einer Seite. Tertiäre Verknüpfungen verknüpfen eine Seite mit einer anderen Seite an beliebiger Stelle der Struktur. Alle tertiären Verknüpfungen haben dieselbe Form.
Die europäische Patentanmeldung 0 638 870 offenbart ein System, bei dem ein semantisches Netzwerk einer Reihe von Tabellen zugeordnet wird, die zum Speichern der semantischen Informationen verwendet werden. Daten werden nicht in den Knoten des Netzwerks gespeichert, und bei Abfragen werden die Tabellen nach den relevanten Daten durchsucht.
Viele frühere Implementierungen semantischer Netzwerke waren sehr komplex und in bezug auf die Speichernutzung ineffizient. Daher wurden sie wenig verwendet. Ein Beispiel für die eingebrachte Komplexität ist die Speicherung beträchtlicher Mengen von Informationen mit einem Subjekt (einem Datenelement) an einem Ende einer Beziehung, die das Subjekt am anderen Ende einer Beziehung betreffen. Während dadurch die Notwendigkeit umgangen werden kann, das Subjekt am anderen Ende der Beziehung abzufragen, um Informationen von ihm zu erhalten, hat es bei jedem Subjekt die Komplexität zur Folge.
Daher wäre es vorteilhaft, eine effiziente Implementierung eines semantischen Netzwerks bereitzustellen, das für die Verwendung mit gängigen verfügbaren Programmiersprachen wie C und C++ geeignet ist.

Offenbarung der Erfindung

Dementsprechend bietet die Erfindung eine als semantisches Netzwerk angeordnete Datenbank gemäß der folgenden Ansprüche.
Die Beziehungsinformationen, die an den Knoten über Beziehungen zu anderen Knoten gespeichert sind, umfassen vorzugsweise ein Token, das die Art der Beziehung angibt. Das Token kann problemlos an einem kleinen Speicherplatz, vorzugsweise in zwei Bytes, gespeichert werden, was eine sehr viel effizientere Speicherung ist, als wenn der Beziehungsname selbst mit der Beziehung gespeichert würde. Nicht zwei Byte große Speichermengen können bei entsprechenden Änderungen der Anzahl der unterstützten Beziehungsnamen verwendet werden. Das Speichern des Namens selbst erfordert im allgemeinen ein Byte Speicherplatz pro Zeichen des Beziehungsnamens, und so erfordert beispielsweise die Speicherung von "HasMember" als Beziehungsname zehn Byte Speicherplatz, einschließlich eines Abschluß bytes. Durch die Verwendung eines Tokens sind zwei Byte erforderlich, wobei die Umsetzung in einen Beziehungsnamen vorzugsweise durch Informationen erfolgt, die in der Datenbank in bezug auf Token zu entsprechenden Beziehungsnamen enthalten sind. In einem anderen Ausführungsbeispiel werden die Informationen bezüglich der Token zu entsprechenden Beziehungsnamen nicht in der Datenbank gespeichert, sondern stehen mehreren Datenbanken gemeinsam zur Verfügung, d. h. für mehrere semantische Netzwerke wird nur eine einzige Kopie aufbewahrt.
In einem bevorzugten Ausführungsbeispiel enthalten Zweige der verzweigten Struktur eine Beziehung, wobei die Beziehung Flags aufweist, die angeben, daß die Beziehung Bestandteil der verzweigten Struktur ist. Die Flags können auch andere Daten bezüglich der Beziehung angeben, beispielsweise die Art des zugehörigen Subjekts oder die Tatsache, daß die Beziehung von einem in Beziehung stehenden Knoten in eine Richtung auf diesen Knoten zeigt.
In einem weiteren Aspekt der vorliegenden Erfindung können sich die Beziehungsinformationen auf einen "virtuellen" Knoten beziehen, bei dem die Beziehungsinformationen selbst die Daten enthalten, die sich im virtuellen Knoten befunden hätten. Die Daten für den virtuellen Knoten können auch an einer Stelle gespeichert werden, auf die die Beziehungsinformationen zeigen, wobei diese Stelle nicht Bestandteil der verzweigten Struktur ist. Durch die Verwendung eines Tokens zum Kennzeichnen der Beziehungsart wird die Datenmenge reduziert, die über einen "virtuellen" Knoten gespeichert werden muß.

Kurzbeschreibung der Zeichnungen

Ein Ausführungsbeispiel der Erfindung wird jetzt als Beispiel und unter Bezugnahme auf die begleitenden Zeichnungen beschrieben, in denen:
Fig. 1 eine schematische Zeichnung eines semantischen Netzwerks nach dem Stand der Technik ist;
Fig. 2 ein Blockdiagramm eines Teils eines semantischen Netzwerks ist, das gemäß der vorliegenden Erfindung implementiert wurde;
Fig. 3 ein Diagramm einer einzeln verbundenen Liste der Beziehungsdeskriptoren ist, die im semantischen Netzwerk der vorliegenden Erfindung verwendet werden; und
Fig. 4 ein Diagramm einer einzeln verbundenen Liste der freien Blöcke im Speicher ist, die für das semantische Netzwerk der vorliegenden Erfindung zugeordnet sind.

Detaillierte Beschreibung der Erfindung

Fig. 1 zeigt in schematischer Form ein semantisches Netzwerk 100 nach dem Stand der Technik. Das Netzwerk hat einen "Stammknoten" 102, der bei der Erstellung des Netzwerks erstellt wird. Ein Knoten ist ein Datenelement oder Subjekt, das durch Daten dargestellt wird, die in einem Bereich des Computerspeichers gespeichert werden. Weitere Knoten werden an 104 und 106 gezeigt. Diese Knoten werden erstellt, nachdem das Netzwerk (einschließlich des Stammknotens) erstellt wurde. Derartige Knoten können nur erstellt werden, indem ein Containersubjekt angegeben und dann gleichzeitig der Knoten mit einer Beziehung zu dem Containersubjekt erstellt wird. Daher weist jeder Knoten bei seiner Erstellung eine Beziehung auf, bei der es sich um eine Beziehung zu seinem Containersubjekt handelt. Diese Beziehung wird auf dem Knoten in derselben Weise gespeichert wie jede andere Beziehung. Für die Knoten 104 und 106 ist der Stammknoten 102 das Containersubjekt. Der Pfad von den einzelnen Knoten zu ihren Containersubjekten wird in Fig. 1 durch die durchgezogenen Linien 130 bis 144 dargestellt. Obwohl Fig. 1 ein semantisches Netzwerk zeigt, bei dem jedes Containersubjekt eine Linie zu zwei untergeordneten Subjekten aufweist, kann es sich bei der Anzahl der untergeordneten Subjekte um jede beliebige ganze Zahl handeln. Dieses Linien stellen ein azyklisches Containment-Diagramm dar. Ein Subjekt, bei dem es sich um ein Containersubjekt für ein anderes Subjekt handelt, kann erst dann gelöscht werden, wenn alle Subjekte, für die es ein Containersubjekt darstellt, gelöscht wurden. Dies wird durch das Setzen eines Flags erzielt, das der Beziehung zwischen dem Containersubjekt und dem enthaltenen Subjekt zugeordnet ist, um anzugeben, daß das Containersubjekt nicht gelöscht werden kann. Jedes Subjekt ist durch eine Folge von Linien mit allen anderen Subjekten verbunden. Daher gibt es stets einen Pfad vom Stammsubjekt, das durch den Stammknoten repräsentiert wird, zu allen anderen Subjekten im Netzwerk.
Diesem Diagramm überlagert ist ein zyklisches Diagramm, das Beziehungen zwischen beliebigen Subjektpaaren zeigt. Derartige Beziehungen sind durch die gestrichelten Linien 150, 152 dargestellt. Sie zeigen eine Beziehung eines Subjekts zu einem anderen Subjekt an. Diese Beziehungen können zwischen beliebigen im Netzwerk enthaltenen Subjekten bestehen. Die Beziehung kann zwischen einem Subjekt und seinem Container oder sogar zwischen einem Subjekt und dem Stammknoten bestehen.
Eine Beziehung ist eine Assoziation zwischen Subjekten. Beispiele für Beziehungsarten sind "wird verwaltet von", "ist Manager von", "wird beschäftigt von" oder "ist ein Mitarbeiter von".
Im bevorzugten Ausführungsbeispiel wird das semantische Netzwerk zum Speichern von Subjektdetails verwendet. Ein Subjekt ist ein Eintrag in einer Datenbank, die beispielsweise Informationen bezüglich der Ressourcen in einem Datenverarbeitungssystem enthält. Für Dateien und Systemsubjekte, deren Details im semantischen Netzwerk gespeichert werden, können die Beziehungen beispielsweise "befindet sich auf" lauten. Um auf die gespeicherten Informationen zuzugreifen, wird zunächst das Subjekt gesucht, über das Informationen eingeholt werden sollen. Hierzu wird durch das semantische Netzwerk navigiert, wobei die azyklischen Containment-Beziehungen vom Stammknoten traversiert werden, um das gewünschte Subjekt aufzufinden. Sobald das Subjekt gefunden wurde, werden innerhalb jedes einzelnen Subjekts die Daten für das Subjekt sowie Informationen darüber gespeichert, welche Beziehungen das Subjekt zu anderen in Beziehung stehenden Subjekten aufweist und welches die Identität dieser anderen in Beziehung stehenden Subjekte ist. Sollten weitere Informationen über ein in Beziehung stehendes Subjekt benötigt werden, wird ein in diesem Subjekt gespeicherter Zeiger auf das in Beziehung stehende Subjekt verwendet, um zu den Daten für das in Beziehung stehende Subjekt zu wechseln. Auf diese Weise ist die Navigation innerhalb des semantischen Netzwerks möglich. Im obigen Beispiel ist es möglich, Informationen über die lokalisierte Datei zu finden, einschließlich beispielsweise Informationen darüber, auf welchem DASD-Laufwerk (Direct Access Storage Drive, Direktzugriff-Speicherlaufwerk) sie gespeichert ist oder auf welchem System sich die Datei befindet. Weitere Informationen über das DASD stehen an diesem Knoten nicht zur Verfügung, aber die Beziehung von der Datei zum DASD kann traversiert werden, um zum DASD zu gelangen und weitere Informationen über es herauszufinden. Diese Beziehungen können beispielsweise Informationen enthalten, die alle auf diesem DASD gespeicherten Dateien auflisten. Die Beziehung vom DASD zu einer anderen Datei kann unter Verwendung dieser Beziehungsdaten traversiert werden.
Das semantische Netzwerk im bevorzugten Ausführungsbeispiel besteht aus einem Permanentspeicherbereich, der in einen Header und in Speicherpakete unterteilt ist. Bei dem Permanentspeicher kann es sich um einen nichtflüchtigen Speicher handeln, wenn die im semantischen Netzwerk gespeicherten Informationen erhalten bleiben sollen, oder um einen flüchtigen Speicher, wenn die Informationen nicht erhalten bleiben müssen. Der Header definiert Informationen, die für das Netzwerk in seiner Gesamtheit benötigt werden. Der Header wird weiter unten unter Bezugnahme auf Beispiel 1 beschrieben. Die Pakete entsprechen entweder einem Knoten 102, 104, 106 im semantischen Netzwerk von Fig. 1 (Subjektdeskriptorpakete, unten unter Bezugnahme auf Beispiel 3 beschrieben) oder einem Deskriptor für die Beziehung 150, 152, der im semantischen Netzwerk von Fig. 1 verwendet wird (Beziehungsdeskriptorpakete, unten unter Bezugnahme auf Beispiel 2 beschrieben). Zu speichernde Daten (Subjekte oder Beziehungen) werden den Paketen zugewiesen. Ein Paket ist ein benachbarter Satz von Bytes des Speichers mit einem zwei Byte langen Deskriptor als Präfix. Die Pakete, die Knoten entsprechen, können auch Erweiterungspakete haben, die verwendet werden, um Informationen zu speichern, die nicht mehr in das Subjektpaket passen. Diese Pakete werden weiter unten unter Bezugnahme auf die Beispiele 4 und 5 beschrieben.
Fig. 2 zeigt einen Teil eines Ausführungsbeispiels eines semantischen Netzwerks, das gemäß der vorliegenden Erfindung implementiert wurde. Die ovalen Formen 104, 108, 110, 112 entsprechen jeweils den entsprechend numerierten Knoten des dem Stand der Technik entsprechenden semantischen Netzwerks von Fig. 1. Die Zeiger 134, 136, 138 entsprechen den entsprechend numerierten Linien von Fig. 1, die als Bestandteil des azyklischen Containment-Diagramms verwendet werden. Der Zeiger 152 ent spricht derselben numerierten Linie in Fig. 1, die verwendet wird, um eine Beziehung zwischen Knoten darzustellen. Knoten, Linien und Zeiger, die in Fig. 1 gezeigt und in Fig. 2 nicht gezeigt werden, wurden nur zum Zwecke der Übersichtlichkeit weggelassen, und sie sind in der Struktur des Ausführungsbeispiels von Fig. 2 vorhanden, obwohl sie nicht in Fig. 2 selbst gezeigt werden. Die Begriffe Knoten und Subjekt können untereinander ausgetauscht werden, wobei der Begriff Knoten verwendet wird, wenn auf das Element Bezug genommen wird, das über Linien als Bestandteil eines Netzwerks verbunden ist, und der Begriff Subjekt verwendet wird, wenn auf das Element als Datenelement Bezug genommen wird.
Wenn nun auf den Knoten 112 Bezug genommen wird, bestehen die Informationen an diesem Knoten aus den vier Bereichen 410, 411, 415 und 419. Der erste Bereich 410 ist ein Satz von Flags für den Knoten selbst, die angeben, ob es sich bei dem Knoten um eine Ganzzahl, einen Gleitkommawert, eine Zeichenfolge oder eine Sequenz handelt, ob es sich bei diesem Knoten um einen Containerknoten für einen anderen Knoten handelt (was bei 112 nicht der Fall ist), ob der Knoten von einem Prozeß vor Änderungen durch alle anderen Prozesse gesperrt wurde und ob der Knoten gelöscht wurde. Die Flags werden in Beispiel 3 als "sflags" bezeichnet.
Der zweite Bereich 411 ist die erste Beziehung, die gegenwärtig an diesem Knoten vorhanden ist. Dieser Bereich 411 ist in drei Teile aufgeteilt, wobei der erste Teil 412 ein Satz von Flags ist, die zu der Beziehung gehören. Die Flags 412 haben dieselbe Bedeutung wie die Flags 410 oben, werden jedoch auf die Beziehung und nicht auf das Subjekt angewandt. Die Flags werden in Beispiel 3 als "rflags" bezeichnet. Der zweite Bereich 413 ist ein Token, das verwendet wird, um die Art der Beziehung zu beschreiben. Das an 413 gespeicherte Token ist als "C" gekennzeichnet. Bei dieser Beziehung handelt es sich um die Bezie hung, die erstellt wurde, als das Subjekt erstellt wurde, um ihr Containersubjekt zu identifizieren, und daher wird die Beziehung entsprechend in den Flags 412 für die Beziehung markiert. In Fig. 2 wird das Beziehungs-Token "C" verwendet, um anzugeben, daß es sich um eine Containerbeziehung handelt. Bei der Containerbeziehung muß es sich nicht um eine besondere Art von Beziehung handeln. Jedes Subjekt kann ein anderes Token - und somit eine andere Art von Beziehung - aufweisen, das für die Beziehung zu seinem Containersubjekt verwendet wird. Es muß sich lediglich um die Beziehung handeln, die erstellt wurde, als der Knoten erstellt wurde, und sie muß als die Containerbeziehung markiert sein. Der dritte Teil 414 ist ein Zeiger auf das in Beziehung stehende Subjekt. In Fig. 2 ist dies Knoten 108, bei dem es sich um das Containersubjekt handelt.
Der dritte Bereich 415 ist eine Beziehung zu einem anderen Subjekt 110. Auch er ist in derselben Weise wie der zweite Bereich 411 in die drei Teile 416, 417 und 418 aufgeteilt. Diese Beziehung unterscheidet sich darin, daß es sich um eine durch das Token "E" dargestellte Art von Beziehung handelt. Diese Beziehung ist nicht als Containerbeziehung markiert.
Der vierte Bereich 419 ist der Wert des Subjekts selbst. Die Flags 410 geben die Art des Subjekts - Ganzzahl, Gleitkommawert, Zeichenfolge oder Sequenz - an, d. h. sie geben an, wie die Datenbytes interpretiert werden sollen.
Unter Bezugnahme auf den Knoten 108 werden nun die Unterschiede zwischen dem Knoten 108 und dem Knoten 112 beschrieben. Der Wert des Subjekts, das an 429 gespeichert ist, und die Art des Subjekts, das in den Flags 420 gespeichert ist, kann identisch oder unterschiedlich sein. Die Flags 420 an Subjekt 108 geben an, daß Subjekt 108 ein Containersubjekt ist und erst dann gelöscht werden kann, wenn alle Subjekte gelöscht wurden, das es enthält. Bei der Beziehung 421 kann es sich um dieselbe Art handeln wie bei der in Subjekt 112 gespeicherten Beziehung, oder es kann eine andere Art von Beziehung sein. Die Beziehung 421 zeigt auf Subjekt 104.
Unter Bezugnahme auf den Knoten 110 werden nun die Unterschiede zwischen dem Knoten 110 und dem Knoten 112 beschrieben. Der Wert des Subjekts, das an 439 gespeichert ist, und die Art des Subjekts, das in den Flags 430 gespeichert ist, kann identisch oder unterschiedlich sein. Die Flags 430 an Subjekt 110 geben an, daß es sich bei Subjekt 110 um ein Containersubjekt handelt, das erst dann gelöscht werden kann, wenn alle Subjekte gelöscht wurden, die es enthält. Bei der Beziehung 431 kann es sich um dieselbe Art von Beziehung handeln wie bei der im Subjekt 112 gespeicherten Beziehung, oder es kann eine andere Art von Beziehung sein. Die Beziehung 431 zeigt auf Subjekt 104. Die Beziehung 435 bezieht sich auf ein als "virtuelles Subjekt" bezeichnetes Subjekt, d. h., ein Subjekt, bei dem die Beziehung eindirektional auf das in Beziehung stehende Subjekt verläuft und bei dem das in Beziehung stehende Subjekt (sein Wert) in der Beziehung selbst enthalten ist. Um dies anzuzeigen, wird ein Bit in den Flags 436 verwendet. Das Token 437 wird verwendet, um die Art der Beziehung in derselben Weise wie für jede andere Beziehung anzugeben. Das hier verwendete Token ist "B", aber es könnte auch "C" oder "E" oder ein anderes gültiges Token sein, wenn die Beziehung einem anderen gültigen Token entsprechen würde. Anstelle eines Zeigers an 438 wird der tatsächliche Wert des Subjekts gespeichert. Hierbei handelt es sich um eine Ganzzahl, einen Gleitkommawert, eine Zeichenfolge oder ein Subjekt, je nachdem, was in den Beziehungs-Flags 436 enthalten ist. Das Subjekt, auf das die Beziehung 435 zeigt, entspricht keinem Knoten im dem Stand der Technik entsprechenden semantischen Netzwerk von Fig. 1, da das Netzwerk nach dem Stand der Technik keine derartigen virtuellen Subjekte unterstützt.
Die Token 413, 417, 423, 433, 437, 443 werden verwendet, um eine Beziehungsart anzugeben. In Fig. 2 werden die Token "B", "C" und "E" verwendet, um drei Arten von Beziehungen zu beschreiben. Die Beziehungsdeskriptoren 460 werden verwendet, um nachzusehen, welcher Art von Beziehung ein Token entspricht. Ein Token "B" entspricht beispielsweise einem Beziehungsdeskriptor an 465, 466, wobei ein Token "B" an 465 und der zugehörige Beziehungsname an 466 gefunden wird.
Die Implementierung des semantischen Netzwerks gemäß der vorliegenden Erfindung, die in Fig. 2 dargestellt wird, wird jetzt detailliert dadurch beschrieben, daß die im Speicher erstellten Datenstrukturen beschrieben werden, die den oben beschriebenen Strukturen entsprechen. Als erstes soll ein Header für das semantische Netzwerk in seiner Gesamtheit beschrieben werden, danach ein Paket, das als ein Beziehungsdeskriptor verwendet wird, dann ein Subjektdeskriptorpaket und zum Abschluß die Erweiterungspakete für Subjekte und Beziehungen. Header BEISPIEL 1
Beispiel 1 zeigt die Struktur im Speicher eines Headers für ein semantisches Netzwerk, das gemäß der vorliegenden Erfindung implementiert wurde.
"eyec" ist der Kennzeichner oder Name, der für dieses Release eines semantischen Netzwerks verwendet wird. Er kann beispielsweise von einem Browser des semantischen Netzwerks verwendet werden, um festzustellen, daß es sich bei der Struktur im Speicher tatsächlich um ein semantisches Netzwerk handelt, und um die Versionsnummer des semantischen Netzwerks zu bestimmen. "size" ist die Summe von Bytes, die diesem semantischen Netzwerk im Speicher zugeordnet wurde. Bei dem verwendeten Speicher kann es sich um ein gemeinsam genutztes Speichersegment des Direktzugriffsspeichers oder um eine in einem nichtflüchtigen Speicher gespeicherte Datei handeln. Die Datei wird von einem Datei-Manager verwaltet, der Bestandteil eines Betriebssystems ist. Im bevorzugten Ausführungsbeispiel wird das UNIX-Betriebssystem verwendet (UNIX ist ein eingetragenes Warenzeichen in den USA und in anderen Ländern, das ausschließlich von X/Open Company Limited lizensiert wird). "nfree" ist die Anzahl freier Bytes innerhalb der Summe von Bytes, die durch "size" definiert wird, die innerhalb des Speichers oder der Datei frei sind. Bei der Initialisierung des semantischen Netzwerks werden alle Bytes des Speichers in Paketen angeordnet, die Pakete können jedoch Bytes haben, die alle frei sind oder Informationen über Subjekte oder Beziehungen enthalten können.
"nrel_name" ist die Anzahl von Beziehungsnamen, die in diesem semantischen Netzwerk existieren. Beispiele für Beziehungsnamen sind "wird beschäftigt von" oder "ist Vater von". Alle diese Beziehungsnamen werden durch den Inhalt eines Beziehungsdeskriptorpakets (siehe Beispiel 2) definiert. Es kann viele Instanzen jeder der Beziehungen innerhalb eines einzigen semantischen Netzwerks geben. Ein Vater mehrerer Kinder kann beispielsweise mehrere Beziehungen "ist Vater von" haben. Es gibt jedoch nur einen einzigen Beziehungsnamen "ist Vater von". "nsubj" ist die Anzahl der Subjekte. Ein Subjekt in dem gemäß der vorliegenden Erfindung implementierten semantischen Netzwerk entspricht einem Knoten 102, 104, 106 in dem semantischen Netzwerk in Fig. 1. Jedes Subjekt ist durch den Inhalt eines Subjektdeskriptorpakets definiert (siehe Beispiel 3). "nreln" ist die Summe der Halbbeziehungen, die im Netzwerk vorhanden sind. Eine Halbbeziehung ist eine Beziehung zwischen einem ersten und einem zweiten Knoten. In Fig. 1 existiert zwischen dem Knoten 114 und dem Knoten 118 eine Halbbeziehung 150. Die Beziehung ist direktional, was durch die in Fig. 1 gezeigte Pfeilspitze dargestellt wird. Wenn der Knoten 118 eine ähnliche Beziehung zu Knoten 114 aufweist wie Knoten 114 zu Knoten 118, dann gibt es eine weitere Halbbeziehung, die Knoten 118 mit Knoten 114 verbindet, wobei die Pfeilspitze in die entgegengesetzte Richtung zeigt.
"pcat" ist die Primärkategorie-Distanzadresse. Primärkategorie ist ein anderer Begriff für den Stammknoten. Es handelt sich also um die Distanzadresse in der Struktur des semantischen Netzwerks, an der die Informationen zum Stammknoten oder -subjekt zu finden sind. Die Daten an diesem Speicherort werden in derselben Weise interpretiert wie bei allen anderen Subjekten.
Innerhalb eines einzigen semantischen Netzwerks kann es viele verschiedene Beziehungsnamen geben. Der Header enthält einen Ankerzeiger für eine einzeln verbundene Liste der Beziehungsdeskriptoren für das semantische Netzwerk. Diese Liste wird in Fig. 3 abgebildet. "relnhead" in Beispiel 1 ist ein Zeiger 210 auf den ersten Eintrag 230 in einer Liste der Beziehungsdeskriptoren 230, 232, 234, 236, die für diese Datenbank definiert wurden. Jeder Beziehungsdeskriptor hat einen Zeiger auf den nächsten Beziehungsdeskriptor. "relntail" ist ein Zeiger 220 auf den letzten Eintrag 236 in einer Liste der Beziehungsdeskriptoren, die für diese Datenbank definiert wurden. Jeder Beziehungsdeskriptor wird in einem Paket (unten beschrieben) definiert, wobei das Paket einen Zeiger ("next") auf den nächsten Beziehungsdeskriptor in der Liste enthält. Wenn man auf diese Weise vom Eintrag "relnhead" im Header ausgeht, kann die verbundene Liste der Beziehungsdeskriptoren verwendet werden, um einen Beziehungsdeskriptor schnell zu finden, wenn vom Listenkopf ausgegangen wird. Außerdem kann das Ende der Liste schnell mit "relntail" lokalisiert werden, um einen zusätzlichen Beziehungsdeskriptor einzufügen. "relntree" ist ein Zeiger auf einen separaten, binären überlagernden Baum, der in einer herkömmlichen Weise verwendet wird, um einen Beziehungsdeskriptor, dessen Name bekannt ist, schneller zu finden. Der Header umfaßt einen Ankerzeiger für eine einzeln verbundene Liste der freien Blöcke 330, 332, 334, 336, 338, 340, 342 in dem Speicher, der für das semantische Netzwerk zugewiesen ist. Diese Liste wird in Fig. 4 gezeigt. "freehead" ist ein Zeiger 310 auf den ersten freien Block 330 des Speichers, der weder dem Header selbst noch einem Paket, das zum Speichern von Details zu Beziehungen oder einem Subjekt verwendet wird, zugeordnet wurde. Jeder Block freien Speichers hat einen Zeiger auf den nächsten freien Speicherblock. "freeblok" ist ein Zeiger 320 auf den größten Block 332 des freien Speichers, der für die Zuordnung verfügbar ist. Dieser Zeiger wird verwendet, damit im Laufe der Zeit durch Zuordnen von Speicher aus dem größten verfügbaren Block eine größere Chance besteht, daß kleinere Blöcke freien Speichers zusammengefaßt werden. Darüber hinaus besteht auch die größte Chance, daß die in den Block einzufügenden Daten in den zugeordneten Speicherblock passen. Aus der Beschreibung der Funktion von "freeblok" ist zu erkennen, daß es nicht entscheidend ist, jederzeit auf den allergrößten Speicherblock zu zeigen; der Zeiger muß die meiste Zeit auf einen der größten Blöcke zeigen, um die gewünschte Funktion auszuführen.
"ncomit" ist die Häufigkeit, mit der Daten festgeschrieben wurden. Dies gibt an, wie oft die Daten im semantischen Netzwerk aktualisiert wurden. In einer einfachsten Form des Netzwerks, bei dem nicht die Möglichkeit besteht, das Netzwerk zu sperren, kann dieser Wert verwendet werden, um festzustellen, ob sich das semantische Netzwerk seit einem vorherigen Zugriff verändert hat. "lockid" ist die ID der Entität, die dieses semantische Netzwerk sperren ließ. Bei der Entität handelt es sich beispielsweise um einen Prozeß. Die ID kann jeder beliebige eindeutige Kennzeichner sein, der die Entität kennzeichnet, die das Netzwerk sperren ließ. Eine Sperre ist ein Mechanismus, durch dessen Verwendung einer Ressource ein derartiges semantisches Netzwerk auf den Inhaber der Sperre beschränkt ist. Die Entität fordert die Sperre für das semantische Netzwerk an. Wenn der Entität die Sperre gewährt wurde, wird die ID der Entität in den Header des semantischen Netzwerks gestellt. Sobald die Entität diese Sperre erhält, kann keine andere Entität das semantische Netzwerk aktualisieren, für das die Sperre eingegangen ist. In einem bevorzugten Ausführungsbeispiel erhält die Entität die Sperre für das gesamte semantische Netzwerk und lokalisiert dann das Subjekt, die Beziehung oder den Beziehungsdeskriptor, für das, die bzw. den sie eine Sperre wünscht, und prüft außerdem ein Sperr-Flag, das mit diesem Subjekt, dieser Beziehung oder diesem Beziehungsdeskriptor in Beziehung steht. Wenn das Sperr-Flag nicht angibt, daß das Subjekt, die Beziehung oder der Beziehungsdeskriptor bereits von einer anderen Entität gesperrt wurde, sperrt die Entität das Subjekt, die Beziehung oder den Beziehungsdeskriptor und gibt dann die Sperre für das gesamte semantische Netzwerk frei. Wenn sie die Sperre für das Subjekt, die Beziehung oder den Beziehungsdeskriptor aufheben möchte, wird der Vorgang wiederholt, um die Sperre aufzuheben. Beziehungspaket BEISPIEL 2
Beispiel 2 zeigt die Struktur im Speicher eines Beziehungsdeskriptorpakets für ein semantisches Netzwerk, das gemäß der vorliegenden Erfindung implementiert wurde.
"len" ist die Größe bzw. Länge des Pakets, sie wird in Speicherbytes gemessen. "next" ist ein Zeiger 231, 233, 235 auf das nächste Beziehungsdeskriptorpaket in der einzeln verbundenen Liste, die in Fig. 3 gezeigt wird. "next" wird in Verbindung mit "relnhead" und "relntail", die sich im Header des semantischen Netzwerks befinden, verwendet, um die Liste zu bilden. In einem bevorzugten Ausführungsbeispiel wird dem Netzwerk ein binärer Baum, der von der verbundenen Liste der Beziehungspakete getrennt und bezüglich der Namen der Beziehungen codiert ist, überlagert. Dieser binäre Baum verwendet "low_tree" als einen Zeiger auf Beziehungsdeskriptorpakete mit Namen mit einer niedrigeren Position im binären Baum der Beziehungsdeskriptornamen. "high_tree" ist ein entsprechender Zeiger auf Beziehungsdeskriptorpakete, die Namen in einer höheren Position ha ben. Ohne den binären Baum muß die Suche nach einem Beziehungsnamen die Zeiger in der einzeln verbundenen Liste von Beziehungen durchlaufen, die in Fig. 3 gezeigt wird. Mit dem binären Baum wird der benötigte Deskriptor schneller gefunden. Ein solcher binärer Baum bzw. jede andere Art von Baum ist jedoch kein wesentlicher Bestandteil der Erfindung.
"rel_num" ist ein Kennzeichner oder Token, der bzw. das verwendet wird, um diese Beziehung zu kennzeichnen. "rel_num" wird in den Subjektdeskriptorpaketen verwendet, um die Art einer Beziehung zu kennzeichnen. Auf diese Weise muß in jedem der Subjektdeskriptorpakete nur ein Token gespeichert werden, und der Name der Beziehung kann durch Suchen in dem Beziehungsdeskriptorpaket herausgefunden werden, das dieses Token in seinem Eintrag "rel_num" aufweist. Dies macht die Subjektdeskriptorpakete sehr viel effizienter hinsichtlich der Speicherung. "name[1]" ist der Name der als Text gespeicherten Beziehung, er lautet beispielsweise "hat Mitglied" oder "wird beschäftigt von". Der Text wird durch ein Null-Zeichen abgeschlossen. Subjektpaket BEISPIEL 3
Beispiel 3 zeigt die Struktur im Speicher eines Subjektdeskriptorpakets für ein semantisches Netzwerk, das gemäß der vorliegenden Erfindung implementiert wurde. Der Subjektdeskriptor enthält einen Subjekt-Header, der einen Paket-Header und einen Subjekt-Header aufweist, der die Anzahl von Beziehungen enthält, über die dieses Subjekt verfügt. Es folgen Details für jede der Beziehungen, die dieses Subjekt hat. Abschließend folgen die Daten für das Subjekt selbst.

Subjekt-Header

"len" ist die Größe bzw. Länge des Pakets, sie wird in Speicherbytes gemessen. "next" ist ein Zeiger auf das Subjekterweiterungspaket, sofern vorhanden. Subjekterweiterungspakete werden unten beschrieben. Wenn kein Subjekterweiterungspaket vorhanden ist, enthält "next" keinen relevanten Wert. "sflags" ist ein Satz von Flags, die als digitales Muster in einem einzelnen Byte gespeichert sind. Die Flags, die in Subjektpaketen verwendet werden und zu den Subjektinformationen gehören, werden wie folgt definiert. Die beiden niederwertigen Bit werden verwendet, um zu definieren, ob es sich bei dem Subjekt um eine Ganzzahl, einen Gleitkommawert, eine Zeichenfolge oder eine Sequenz handelt. Das nächste Bit, "Kategorie", gibt an, ob es sich bei diesem Subjekt um ein Containersubjekt für ein anderes Subjekt handelt. Dies wird verwendet, um die Nicht- Löschbarkeit dieses Subjekts zu erzwingen, bis alle Subjekte, für die es als Containersubjekt fungiert, gelöscht wurden. Das nächste Bit wird nicht verwendet. Das nächste Bit ist ein "Sperr"-Bit, das, sofern zutreffend, zum Kennzeichnen der Entität verwendet wird, die dieses Subjekt sperren ließ. Das nächste Bit ist ein "Lösch"-Bit, das verwendet wird, um anzugeben, ob dieses Subjekt gelöscht wurde. Die beiden hochwertigen Bit werden nicht verwendet. "nrel" ist die Anzahl der Beziehungen, über die dieses Subjekt gegenwärtig verfügt. Auf den ersten Teil des Subjekt-Headers folgen Informationen, die die einzelnen "nreln"-Beziehungen kennzeichnen, über die dieses Subjekt gegenwärtig verfügt. Die zum Definieren einer dieser Beziehungen verwendete Struktur wird "nrel" Mal wieder holt, um jede der Beziehungen zu beschreiben. Ein Subjektpaket wird de facto als ein Paket mit einer festen Anzahl von Beziehungen definiert, wobei "nrel" die Zahl derjenigen dieser Beziehungen angibt, die gültige Daten aufweisen. In einem bevorzugten Ausführungsbeispiel lautet diese feste Zahl 4. Die restlichen Beziehungen enthalten keine gültigen Daten, werden aber mit gültigen Daten gefüllt, wenn zu diesem Subjektpaket eine Beziehung hinzugefügt wird. "nrel" wird aktualisiert, um diese neue Anzahl von Beziehungen, die sich gegenwärtig in diesem Paket befinden, widerzuspiegeln. "nrel" ist niemals größer als die feste Anzahl von Beziehungen, für die diesem Subjektpaket Speicher zugeordnet wurde. Wenn für ein Subjektpaket weitere, über die feste Anzahl hinausgehende Beziehungen benötigt werden, wird ein Subjekterweiterungspaket verwendet, das später beschrieben wird.
"rflags" ist ein Satz von Flags, die in Subjektpaketen verwendet werden und zu Beziehungsinformationen gehören. Sie unterscheiden sich bezüglich des Inhalts von den oben beschriebenen Flags für Subjektinformationen. Die beiden niederwertigen Bit werden verwendet, um zu definieren, ob es sich bei dem zugehörigen Subjekt, d. h. dem Subjekt am anderen Ende der Beziehung, um eine Ganzzahl, einen Gleitkommawert, eine Zeichenfolge oder eine Sequenz handelt. Drei der nächsten vier Bit werden in derselben Weise definiert wie bei "sflags", d. h. "Kategorie", "Sperre" und "Löschen". Das Bit, das bei "sflags" nicht verwendet wird und undefiniert ist, wird in "rflags" als "Erweiterungs"-Bit definiert. Es gibt an, ob für ein "virtuelles" Subjekt ein Erweiterungspaket vorhanden ist. "Virtuelle" Subjekte werden im nächsten Abschnitt definiert, und die Auswirkung des "Erweiterungs"-Bits, das sich darauf bezieht, wie "rnum" interpretiert werden muß, wird unten in Zusammenhang mit "rnum" beschrieben. Das nächste Bit wird verwendet, um anzugeben, ob das zugehörige Subjekt ein reales Subjekt ist, d. h. ein Subjekt in einem separaten Subjektpaket, oder ein "virtuelles" Subjekt, d. h. ein Subjekt, bei dem die Beziehung eindirektional ist und bei dem das zugehörige Subjekt (sein Wert) in der Beziehung selbst enthalten ist. Ein Beispiel für die Verwendung eines virtuellen Subjekts ist der Fall, in dem das Subjekt selbst eine Datendatei ist und das zugehörigen Subjekt der Status "Read-Only" (R/O, Nur-Lesen) ist. Der zugehörige Subjektwert "R/O" paßt problemlos in den Speicherbereich, der verwendet wird, um die Beziehung selbst zu beschreiben, und daher muß das zugehörige Subjekt nicht wirklich ein separates Subjekt sein, dessen Wert und Beziehungen an einem separaten Knoten gespeichert werden. Anstelle des Zeigers auf das zugehörige Subjekt wird der Wert des Subjekts selbst gespeichert. Dies hat den Vorteil einer effizienteren Speichernutzung. Es bedeutet jedoch auch, daß es nicht möglich ist, die Beziehung zu dem und von dem zugehörigen Subjekt zu traversieren und alle Datendateien zu finden, die den Status "Read-Only" haben. Das höchstwertige Bit "negativ" wird verwendet, um zu kennzeichnen, ob es sich bei der Beziehung um eine negative Beziehung handelt, d. h. ob sie von einem zugehörigen Subjekt aus in eine Richtung auf dieses Subjekt zeigt, anstatt weg von ihr auf ein zugehöriges Subjekt zu zeigen. "rel_num" ist der Kennzeichner bzw. das Token, der bzw. das verwendet wird, um diese Beziehung zu kennzeichnen. In den Subjektdeskriptorpaketen wird nur ein Token gespeichert, und der Name der Beziehung kann herausgefunden werden, indem im Beziehungsdeskriptorpaket nachgesehen wird, das dieses Token in seinem Eintrag "rel_num" aufweist.
Ein Ganzzahl-Subjekt ist lediglich eine Ganzzahl, wobei der Wertebereich von der Anzahl der in der Implementierung der Programmiersprache verwendeten Bit abhängt. In einem bevorzugten Ausführungsbeispiel werden vier Byte verwendet, um Ganzzahlen darzustellen. Aus der Verwendung von vier Byte resultiert ein Bereich zwischen -2³¹ (-2.147.483.648) und +2³¹-1 (2.147.483.647). Ein Gleitkommawert-Subjekt ist eine Gleitkommazahl, und auch hier hängt der Wertebereich von der Anzahl der Bit ab, aber er liegt üblicherweise zwischen 10&supmin;³&sup8; und 10&spplus;³&sup8;. Zeichenfolgensubjekte sind lediglich Folgen von Zeichen, die durch ein Null-Zeichen abgeschlossen werden. Sequenzsubjekte sind ebenfalls Zeichenfolgen, jedoch ohne das Abschlußzeichen. Die Länge der Sequenz erhält man durch Implizieren der im Header gespeicherten Paketlänge abzüglich der festen Länge des Headers.
Für reale Subjekte, d. h. Subjekte, bei denen es sich nicht um virtuelle Subjekte handelt, ist "rnum" die Paketnummer des zugehörigen Subjekts. Hier wird im Speicher ein Zeiger auf den Speicherbereich gespeichert, der verwendet wird, um das Subjektpaket am anderen Ende dieser Beziehung zu speichern. Bei virtuellen Subjekten wird der Inhalt des zugehörigen Pakets und nicht der Zeiger auf dieses Paket als "rival" gespeichert, wenn es sich um ein Ganzzahlsubjekt handelt, als "rfval", wenn es sich um ein Gleitkommawert-Subjekt handelt, als "roval", wenn es sich um ein Zeichenfolgensubjekt handelt und als "rsval", wenn es sich um ein Sequenzsubjekt handelt. Auf diese Weise kann auf den Inhalt des zugehörigen Subjekts zugegriffen werden, ohne daß das Subjekt am anderen Ende der Beziehung gefunden werden muß. (A. D. Ü.: Der Ausdruck "with having to find" ist fehlerhaft. Es muß entweder "by having to find" oder "without having to find" heißen; letzteres wurde in der Übersetzung verwendet. Bitte prüfen.). Die Beziehungen, über die das zugehörige Subjekt selbst verfügt, können jedoch nicht anhand des an diesem Ende der Beziehung gespeicherten Inhalts bestimmt werden, außer natürlich alle Beziehungen direkt zu diesem Subjekt. In einer Ausnahme zu dem oben Gesagten - wenn das Subjekt ein virtuelles Subjekt ist und das Subjekt eine Zeichenfolge ist (was beides anhand des Wertes von "rflags" für diese Beziehung bestimmt werden kann) und wenn die Zeichenfolge mehr als vier Byte lang ist, einschließlich ihres Null-Abschlußzeichens - handelt es sich bei dem, was an diesem Speicherort gespeichert ist, um einen Zeiger auf ein Beziehungserweiterungspaket, das später unter Bezugnahme auf Beispiel 5 beschrieben wird. Ein Beziehungserweiterungspaket wird lediglich als Erweiterung des Wertes eines virtuellen Subjekts verwendet. Das Vorhandensein eines Beziehungserweiterungspakets ist am Setzen des "Erweiterungs"-Bits in "rflags" zu erkennen, das oben erwähnt wurde. Das Setzen des "Erweiterungs"-Bits wird dann verwendet, um festzustellen, ob "rnum" als Zeiger auf das Beziehungserweiterungspaket interpretiert werden soll, ob das "Erweiterungs"-Bit wahr ist oder ob es als ein Wert interpretiert wird, wenn es falsch ist. Der Inhalt dieses Subjektpakets selbst wird als "sival" gespeichert, wenn es sich um ein Ganzzahlsubjekt handelt, als "sfval", wenn es sich um ein Gleitkommawert-Subjekt handelt, als "scval", wenn es sich um ein Zeichenfolgensubjekt handelt und als "ssval", wenn es sich um ein Sequenzsubjekt handelt. Die Vereinigung {..} v; ist eine standardmäßige Kompiliererstruktur, die lediglich bedeutet, daß nur einer der Ausdrücke in den Klammern verwendet wird. Subjekterweiterungspaket BEISPIEL 4
Beispiel 4 zeigt die Struktur im Speicher eines Subjekterweiterungspakets für ein semantisches Netzwerk, das gemäß der vorliegenden Erfindung implementiert wurde. Wie oben erwähnt wurde, bietet ein Subjektdeskriptorpaket nur Platz für eine feste Anzahl von Beziehungen. Diese Einschränkung ist darauf zurückzuführen, daß das Subjektdeskriptorpaket erstellt wird, bevor die Anzahl der Beziehungen bekannt ist. Nach der Erstellung kann es nicht mehr verschoben werden, da sich andere Subjektdeskriptoren in ihren eigenen Beziehungen auf seine Position beziehen. Dieses Problem wird durch die Verwendung eines Subjekterweiterungspakets behoben, das nur Informationen zu Beziehungen enthält. Subjektdaten sind nicht vorhanden. Das Subjekterweiterungspaket ist mit dem Subjektpaket verkettet, um eine einzeln verbundene Liste unendlicher Länge zu bilden. Die verbundene Liste beginnt mit dem Eintrag "next" im Subjektdeskriptorpaket, der auf das erste Subjekterweiterungspaket für dieses Subjekt zeigt. Die Liste wird mit einem Zeiger fortgesetzt, der sich im Eintrag "next" des ersten Subjekterweiterungspakets befindet, der auf das zweite Subjekterweiterungspaket zeigt. Weitere Pakete können mit der Liste verkettet werden. Das letzte Paket in der Liste enthält keinen relevanten Wert im Eintrag "next".
"len" ist die Größe bzw. Länge des Pakets, sie wird in Speicherbytes gemessen. "next" ist ein Zeiger auf das nächste Subjekterweiterungspaket in der einzeln verbundenen Liste, sofern vorhanden. Wenn kein weiteres Subjekterweiterungspaket vorhanden ist, enthält "next" keinen relevanten Wert.
"mxrel" enthält die maximale Anzahl von Beziehungen, die in diesem Subjekterweiterungsblock gespeichert werden können. Die Wahl dieses Werts ist ein Kompromiß zwischen eine großem Wert, der eine Vergeudung von Speicherplatz darstellt, wenn zu viele Subjekterweiterungspakete mit ungenutztem Platz für Beziehungen vorhanden sind, und einem kleinen Wert, wenn ein Bedarf an weiteren Erweiterungspaketen besteht. In einem bevorzugten Ausführungsbeispiel beträgt die maximale Anzahl gespeicherter Beziehungen 10. "nrel" ist die aktuelle Anzahl von Beziehungen, die in diesem Subjekterweiterungsblock gespeichert sind. Die Beziehungsbeschreibung, d. h. "flags", "rel_num", "rnum", "rival", "rfval", "rcval" und "rsval", sind mit den oben beschriebenen, in einem Subjektpaket verwendeten Beschreibungen identisch, und sie werden so oft wiederholt, wie Beziehungen in diesem Subjekterweiterungspaket gespeichert sind. Beziehungserweiterungspaket BEISPIEL 5
Beispiel 5 zeigt die Struktur im Speicher eines Beziehungserweiterungspakets für ein semantisches Netzwerk, das gemäß der vorliegenden Erfindung implementiert wurde. Beziehungserweiterungspakete werden nur verwendet, um virtuelle Subjekte zu unterstützen, die eine Länge von mehr als vier Bytes aufweisen und die nicht hineinpassen, wenn die Implementierung wie oben beim Subjektpaket beschrieben erfolgt. Der tatsächliche Wert des virtuellen Subjekts wird in diesem Beziehungserweiterungspaket gespeichert, und im Subjektpaket (an der als "rnum" gekennzeichneten Stelle) wird ein Zeiger angeordnet, der auf dieses Beziehungserweiterungspaket zeigt.
"len" ist die Größe bzw. Länge des Pakets, sie wird in Speicherbytes gemessen. "next" wird nur verwendet, wenn es sich bei dem virtuellen Subjekt um die Art "Sequenz" handelt und wenn es zum Speichern der tatsächlichen Länge der Sequenz verwendet wird. Ansonsten enthält "next" keinen relevanten Wert.
Der Inhalt dieses virtuellen Subjekts wird als "ival" gespeichert, wenn es sich um ein virtuelles Ganzzahlsubjekt handelt, als "fval", wenn es sich um ein virtuelles Gleitkommawert-Subjekt handelt, als "cval", wenn es sich um ein virtuelles Zeichenfolgensubjekt handelt, und als "sval", wenn es sich um ein virtuelles Sequenzsubjekt handelt. Die Vereinigung {..} v; ist eine standardmäßige Kompiliererstruktur, die bedeutet, daß nur einer der Ausdrücke in den Klammern verwendet wird. Der Wert (niederwertige zwei Bit), der am Speicherort "rflags" des Subjektpakets gespeichert ist, zu dem das virtuelle Subjekt ein zugehöriges Subjekt darstellt, wird verwendet, um den Inhaltstyp des virtuellen Subjekts und somit die zu verwendenden Definitionen innerhalb der Vereinigungsanweisung zu bestimmen.

Anwendungsprogrammierschnittstelle

Es wird eine Anwendungsprogrammierschnittstelle bereitgestellt, mit der das oben beschriebene semantische Netzwerk gehandhabt werden kann. Die Funktion der Schnittstelle wird mit Hilfe einer "C"-Schnittstelle zur Verfügung gestellt. Es werden Aufrufe bereitgestellt, um das semantische Netzwerk einzurichten und zu verwalten und um innerhalb des semantischen Netzwerks zu navigieren und Informationen aus ihm zu extrahieren. Die Aufrufe für das Einrichten und Verwalten des semantischen Netzwerks umfassen:
db_create Erstelle das semantische Netzwerk - initialisiert den zugewiesenen Speicherbereich in Pakete und erstellt einen Stammknoten.
db_delete Lösche das semantische Netzwerk.
db_reset Entferne alle Subjekte und alle Beziehungen.
db_create_relation Erstelle einen Beziehungsdeskriptor - anhand eines bereitgestellten Namens für die Beziehung erstellt er ein Beziehungsdeskriptorpaket und ordnet dieser Beziehung ein Token zu.
db_new_integer, db_new_float, db_new_string, db_new_sequence Erstelle ein neues Subjekt. Es gibt separate Aufrufe für die Erstellung aller vier Subjektarten, die gegenwärtig in dem oben beschriebenen Ausführungsbeispiel des semantischen Netzwerks definiert sind. Wenn ein Containersubjekt vorhanden ist, werden die Art der Beziehung zu diesem Containersubjekt und ein Wert für das Sub jekt sowie ein Subjektdeskriptorpaket erstellt.
db_chg_integer, db_chg_float, db_chg_string, db_chg_sequence Ändere einen Subjektwert. Es gibt separate Aufrufe für das Ändern des Wertes aller vier Subjektarten, die gegenwärtig in dem oben beschriebenen Ausführungsbeispiel des semantischen Netzwerks definiert sind. Anhand des bereitgestellten Subjektnamens und des aktualisierten Werts wird das Subjektdeskriptorpaket mit dem geänderten Wert aktualisiert.
db_chg_rel_integer, db_chg_rel_float, db_chg_rel_string, db_chg_rel_sequence
Ändere einen zugehörigen Subjektwert. Es gibt separate Aufrufe für das Ändern des Wertes aller vier Arten von zugehörigen Subjekten, die gegenwärtig in dem oben beschriebenen Ausführungsbeispiel des semantischen Netzwerks definiert sind.
db_delete_subject Lösche ein Subjekt. Wenn es sich bei dem Subjekt um ein Containersubjekt handelt, d. h. wenn das CATEGORY-Bit in den Flags einer der Beziehungen gesetzt ist, muß dieser Löschvorgang fehlschlagen, um das azyklische Containment-Diagramm beizubehalten. Alle von diesem Subjekt ausgehenden Beziehungen werden gelöscht, mit Ausnahme derjenigen, die für das Containment verwendet werden.
db_virtual_integer, db_virtual_flaot, db_virtual_string, db_virtual_sequence
Erstelle ein neues virtuelles Subjekt. Es gibt separate Aufrufe für das Erstellen aller vier Arten von virtuellen Subjekten, die gegenwärtig in dem oben beschriebenen Ausführungsbeispiel des semantischen Netzwerks definiert sind. Anhand des realen Subjekts, bei dem sich das virtuelle Subjekt tatsächlich befindet, der Art der Beziehung vom realen Subjekt zum virtuellen Subjekt und des Werts des virtuellen Subjekts wird eine Beziehung zum Subjektpaket hinzugefügt.
db_add reln Füge eine neue Beziehung hinzu. Anhand des Subjekts, zu dem eine Beziehung hinzugefügt werden soll, der Art der Beziehung von diesem Subjekt zu dem zugehörigen Subjekt und des Namens des zugehörigen Subjekts wird eine Beziehung zu dem Subjektpaket hinzugefügt.
db_delete_reln Lösche eine Beziehung. Wenn die Beziehung als eine Containerbeziehung markiert ist, d. h. wenn das CATEGORY-Bit in den Flags gesetzt ist, muß dieser Löschvorgang fehlschlagen, um das azyklische Containment- Diagramm beizubehalten. Das zugehörige Subjekt, für das diese Beziehung als Containerbeziehung fungiert, muß zuerst gelöscht werden.

Claims

1. Eine Datenbank, die als semantisches Netzwerk angeordnet ist, in dem

es einen Stammknoten (102) gibt, von dem alle übrigen Knoten (104, 108, 110, 112) in einer verzweigten Struktur (134, 136, 138) abhängen; und

wobei die Datenbank Informationen (406) bezüglich Token (A, B, C, D, E) zu entsprechenden Beziehungsnamen umfaßt;

dadurch gekennzeichnet, daß:

Daten in Datenspeicherbereichen (410-419) an Knoten (104, 108, 110, 112) des Netzwerks gespeichert werden; und

Daten, die in Datenspeicherbereichen an einem ersten Knoten gespeichert sind, Beziehungsinformationen (415) über eine oder mehrere Beziehungen (152) von dem ersten Knoten (112) zu einem oder mehreren zweiten in Beziehung stehenden Knoten (110) umfassen, wobei die Beziehungsinformationen ein Token (417, E) umfassen, das die Art der Beziehung und zweite Knoten (110), die in der verzweigten Struktur nicht mit dem ersten Knoten (112) verbunden sind, kennzeichnet.

2. Eine Datenbank nach Anspruch 1, in der sich die Beziehungsinformationen (415) auf einen virtuellen Knoten beziehen und in der die Beziehungsinformationen selbst die Daten enthalten, die sich im virtuellen Knoten befunden hätten.

3. Eine Datenbank nach Anspruch 2, in der die Daten für einen virtuellen Knoten an einem Speicherort gespeichert werden, auf den die Beziehungsinformationen (415) zeigen, wobei der Speicherort nicht Bestandteil der verzweigten Struktur ist.

4. Eine Datenbank nach einem der vorangehenden Ansprüche, in der die Beziehungsinformationen ein Flag (416) umfassen, das die Art des zugehörigen Subjekts angibt.

5. Eine Datenbank nach Anspruch 4, in der Zweige der verzweigten Struktur eine Beziehung (411) umfassen, deren Flag (412) angibt, daß die Beziehung Bestandteil der verzweigten Struktur ist.

6. Eine Datenbank nach einem der vorangehenden Ansprüche, in der die Beziehungsinformationen (435) ein Flag (436) umfassen, das angibt, daß die Beziehung von einem in Beziehung stehenden Knoten (112) in eine Richtung auf diesen Knoten (110) zeigt.