DE60304066T2

DE60304066T2 - Verfahren zur Normalisierung einer Diskursrepräsentationsstruktur und normalisierte Datenstruktur

Info

Publication number: DE60304066T2
Application number: DE60304066T
Authority: DE
Inventors: Pär Jonas Kirkland Barklund; Michael V. Kirkland Calcagno
Original assignee: Microsoft Corp
Current assignee: Microsoft Corp
Priority date: 2002-01-14
Filing date: 2003-01-13
Publication date: 2006-08-17
Anticipated expiration: 2023-01-14
Also published as: EP1335300B1; US8412515B2; US20080033715A1; ATE321306T1; US20030171915A1; JP4703099B2; EP1335300A1; JP2003233606A; US7295966B2; DE60304066D1

Description

Hintergrund der Erfindung
Die Erfindung betrifft die semantische Analyse von Material in natürlicher Sprache. Die Erfindung betrifft insbesondere die Normalisierung einer linguistischen Struktur, die von einem Verarbeitungssystem für natürliche Sprache bereitgestellt wird.
Für zahlreiche Anwendungen ist eine Schnittstelle für natürliche Sprache von Nutzen, die in der Lage ist, Eingaben von einem Nutzer in natürlicher Sprache anzunehmen und korrekt zu verarbeiten. Derartige Systeme für natürliche Sprache müssen bezüglich linguistischen und konzeptionellen Schwankungen unempfindlich sein. Folglich müssen sie einfach in der Benutzung sein.
Systeme für natürliche Sprache müssen beispielsweise in der Lage sein, mit durch Anhängen von Modifikatoren bedingten Mehrdeutigkeiten, mit durch Quantifiziererbereiche bedingten Mehrdeutigkeiten, mit konjunktions- und disjunktionsbedingten Mehrdeutigkeiten, mit durch Nominalzusammensetzungen bedingten Mehrdeutigkeiten, mit Anaphern, elliptischen Sätzen und dergleichen mehr zurechtkommen.
Bei Systemen aus dem Stand der Technik kommen semantisches Wissen oder heuristisches Wissen nur in begrenztem Umfang zum Einsatz, um Mehrdeutigkeiten bei der Eingabe natürlicher Sprache aufzulösen. Gleichwohl sind derartige Lösungsversuche unerwünscht kompliziert oder ineffizient.
Sogar unter der Annahme, dass ein Ausdruck in natürlicher Sprache einer Verarbeitung für natürliche Sprache unterworfen und eine linguistische Struktur entwickelt werden kann, die die Bedeutung der Eingabe in natürlicher Sprache darstellt, müssen hohe Hürden genommen werden, um jene linguistische Struktur bei Anwendungen zu benutzen, die Eingaben mit einer spezifischen Struktur erwarten. So erwarten beispielsweise zahlreiche herkömmliche Anwendungen die Eingabe von Information in einer vordefinierten Struktur, wobei diese Struktur oftmals von Anwendung zu Anwendung verschieden ist. Die Ausgabe zahlreicher Verarbeitungssysteme für natürliche Sprache steht keine Struktur dar, die für die Eingabe in derartige Anwendungen geeignet ist.
Sogar unter der Annahme, dass eine linguistische Struktur entwickelt werden kann, die die Bedeutung einer Eingabe in natürlicher Sprache darstellt, ergibt sich nicht, dass die linguistische Struktur für die Eingabe in eine Anwendung geeignet ist, bei der die Verwendung von Information gewünscht ist, die durch die Eingabe in natürlicher Sprache dargestellt wird.
Der Beitrag „Disambiguation of Underspecified Discourse Representation Structures under Anaphoric Constraints" von M. Schiehlen, veröffentlicht bei „Proceedings of the Second International Workshop on Computational Semantics", 08.01.1997, Tilburg, NL, stellt einen Algorithmus zur Beseitigung von Mehrdeutigkeiten für eine Bereichsauflösung und eine Voraussetzungseinordnung unter Anapherrandbedingungen dar. Es wird die Möglichkeit der Durchführung einer Anapherauflösung und Voraussetzungseinordnung in einem Umfeld beschrieben, in dem Beziehungen zwischen Bereichen lediglich teilweise bekannt sind. Mit Blick auf die Unterspezifizierung der Bereichsmehrdeutigkeit setzt dieser Lösungsansatz auf den Rayle'schen Formalismus für unterspezifizierte Diskursrepräsentationsstrukturen, der derart erweitert wird, dass er auch beliebige Randbedingungen einer Anapherauflösung abdeckt. Die Figuren auf Seite 6 und 7 zeigen Boxen, Boxenelemente mit damit verknüpften Argumenten, Boxenelemente und damit verknüpfte Argumente einschließlich einer semantischen Darstellung der Diskurseingabe.
Die Druckschrift US-A-5,794,050 versetzt ein Computersystem in die Lage, eine Eingabe in natürlicher Sprache zu interpretieren.
Die Druckschrift US-A-5,873,056 offenbart ein Verarbeitungssystem für natürliche Sprache für eine semantische Vektordarstellung, die mit lexikalischen Mehrdeutigkeiten zurechtkommt.
Die Aufgabe der vorliegenden Erfindung besteht darin, eine verbesserte Diskursrepräsentationsdatenstruktur bereitzustellen, die für eine Diskurseingabe repräsentativ ist. Des Weiteren soll durch die vorliegende Erfindung ein zugehöriges Verfahren bereitgestellt werden.
Die Aufgabe wird durch den Gegenstand der unabhängigen Ansprüche gelöst.
Bevorzugte Ausführungsbeispiele werden durch den Gegenstand der abhängigen Ansprüche beschrieben.
Die vorliegende Erfindung ist ein Verfahren zur Normalisierung einer Diskursrepräsentationsstruktur (discourse representation structure DRS). Die Elemente der Struktur werden derart umgeschrieben und sortiert, dass die Strukturen nach außen hin anders aussehen können, jedoch gleichwohl äquivalent beziehungsweise gleichwertig sind und mit derselben normalisierten Darstellung verknüpft sein können.
Die vorliegende Erfindung kann darüber hinaus eine Datenstruktur für eine Datenrepräsentationsstruktur beinhalten. Die Datenrepräsentationsstruktur wird durch eine Anordnung von Boxen dargestellt, von denen jede einen Satz von Elementen aufweist, der wiederum eine vordefinierte Struktur innehat, die zur Darstellung einer großen Vielfalt linguistischer Information geeignet ist.
Kurzbeschreibung der Zeichnung
1 ist ein Blockdiagramm eines als Beispiel angegebenen Ausführungsbeispieles eines Computers, bei dem die vorliegende Erfindung verwendet werden kann.
2 ist ein Blockdiagramm eines Textanalysesystems, bei dem die vorliegende Erfindung verwendet werden kann.
3 ist ein detaillierteres Blockdiagramm eines semantischen Analysesystems entsprechend einem Ausführungsbeispiel der vorliegenden Erfindung.
4 zeigt ein Flussdiagramm, das allgemein die Verarbeitung einer Analyse (einschließlich UDRS) entsprechend einem Ausführungsbeispiel der vorliegenden Erfindung darstellt.
5A ist ein Diagramm der UDRS-Boxenstruktur.
5B ist ein Flussdiagramm, das die Normalisierung einer UDRS darstellt.
6 ist ein als Beispiel angegebenes Anwendungsschema.
7 ist ein Flussdiagramm, das detaillierter darlegt, wie das System initialisiert wird.
8 ist ein Flussdiagramm, das die Anwendung der semantischen Abbildungsregel auf die Boxenstruktur der UDRS darstellt.
9 ist ein Flussdiagramm, das einen Auflockerungsprozess entsprechend einem Ausführungsbeispiel der vorliegenden Erfindung darstellt.
10 ist ein Flussdiagramm, das die Blurb-Verarbeitung entsprechend einem Ausführungsbeispiel der vorliegenden Erfindung darstellt.
11 ist ein Flussdiagramm, das die Implementierung von Unempfindlichkeitsstrategien (robustness strategies) entsprechend einem Ausführungsbeispiel der vorliegenden Erfindung darstellt.
11–1 ist eine zweite als Beispiel angegebene UDRS-Blockstruktur.
12 ist ein Flussdiagramm, das die Erzeugung von Anfangssuchzuständen entsprechend einem Ausführungsbeispiel der vorliegenden Erfindung darstellt.
13 ist ein vereinfachtes Flussdiagramm, das den Prozess des Suchens der Anfangssuchzustände zur Ermittlung von Lösungsmustern und SemDRS'en entsprechend einem Ausführungsbeispiel der vorliegenden Erfindung darstellt.
14 ist ein detaillierteres Flussdiagramm, das die Suche nach Anfangssuchzuständen zur Ermittlung von Lösungsmustern darstellt.
15 ist ein vereinfachtes Flussdiagramm, das darstellt, wie Muster zur Ermittlung von Lösungsmustern kombiniert oder vereinheitlicht werden.
Detailbeschreibung der als Beispiel angegebenen Ausführungsbeispiele
A. Übersicht
Die vorliegende Erfindung stellt ein System und ein Verfahren zur Normalisierung einer Diskursrepräsentationsstruktur (discourse representation structure DRS) bereit. Die Erfindung wird im Kontext eines semantischen Analysesystems und eines Verfahrens beschrieben, das eine von einem linguistischen Analysesystem für natürliche Sprache aus gegebene linguistische Struktur interpretiert. Die Ausgabe des semantischen Analysesystems ist ein Datenstrukturmodell, das als semantische Diskursrepräsentationsstruktur (semantic discourse representation structure SemDRS) bezeichnet wird. Die vorliegende Erfindung schließt den Gesamtprozess und die Architektur wie auch eine Anzahl von Unterprozessen und Datenstrukturen ein. Um ein besseres Verständnis der vorliegenden Erfindung zu ermöglichen, wird zunächst eine als Beispiel angegebene Umgebung erläutert, in der die vorliegende Erfindung verwendet werden kann. Es ist selbstredend einsichtig, dass die vorliegende Erfindung auch in einer großen Vielzahl anderer Systeme und Umgebungen verwendet werden kann.
B. Als Beispiel angegebene Betriebsumgebung
1 zeigt ein Beispiel einer geeigneten Computersystemumgebung 100, in der die Erfindung implementiert sein kann. Die Computersystemumgebung 100 stellt nur ein Beispiel für eine geeignete Computerumgebung dar und soll keine Beschränkungen hinsichtlich des Verwendungsumfangs oder der Funktionalität der Erfindung nahelegen. Ebenso wenig sollte die Computerumgebung 100 dahingehend interpretiert werden, dass irgendwelche Abhängigkeiten oder Notwendigkeiten bestehen, die durch irgendeine Kombination der bei der als Beispiel angegebenen Betriebsumgebung 100 dargestellten Komponenten bedingt sind.
Die Erfindung kann mit zahlreichen anderen Allzweck- oder Sonderzweckberechnungssystemumgebungen oder Konfigurationen betrieben werden. Beispiele für bekannte Computersysteme, Umgebungen und/oder Konfigurationen, die zur Verwendung mit der Erfindung geeignet sind, umfassen unter anderem Personalcomputer, Servercomputer, Hand- oder Laptopvorrichtungen, Multiprozessorsysteme, mikroprozessorbasierte Systeme, Settopboxen, programmierbare Geräte der Unterhaltungselektronik, Netzwerk-PCs, Minicomputer, Mainframecomputer, verteilte Computerumgebungen, die eines der vorgenannten Systeme oder Vorrichtungen enthalten, und dergleichen mehr.
Die Erfindung kann im allgemeinen Kontext computerausführbarer Anweisungen beschrieben werden, so beispielsweise im Kontext von Programmmodulen, die von einem Computer ausgeführt werden. Im Allgemeinen zählen zu den Programmmodulen Routinen, Programme, Objekte, Komponenten, Datenstrukturen und dergleichen mehr, die bestimmte Aufgaben ausführen oder bestimmte abstrakte Datentypen implementieren. Die Erfindung kann auch in verteilten Computerumgebungen realisiert werden, wo Auf gaben von entfernt angeordneten Verarbeitungsvorrichtungen ausgeführt werden, die über ein Datenübertragungsnetzwerk verbunden sind. In einer verteilten Computerumgebung können Programmmodule sowohl in am Ort befindlichen wie auch in entfernt angeordneten Computerspeichermedien, darunter in Speicherablagevorrichtungen, befindlich sein.
Wie in 1 dargestellt ist, umfasst ein als Beispiel angegebenes System zur Implementierung der Erfindung eine Allzweckcomputervorrichtung in Form eines Computers 110. Komponenten des Computers 110 können unter anderem eine Verarbeitungseinheit 120, einen Systemspeicher 130 und einen Systembus 121 enthalten, der verschiedene Systemkomponenten, darunter den Systemspeicher, mit der Verarbeitungseinheit 120 koppelt. Der Systembus 123 kann ein beliebiger Bus verschiedener Typen von Busstrukturen sein, darunter ein Speicherbus oder ein Speicherkontroller, ein Peripheriebus und ein lokaler Bus, bei dem eine beliebige Busarchitektur aus einer Vielzahl von Busarchitekturen zum Einsatz kommt. Zu den Beispielen für derartige Architekturen zählen der ISA-Bus (industry standard architecture ISA, Industriestandardarchitektur), der MCA-Bus (micro channel architecture MCA, Mikrokanalarchitektur), der EISA-Bus (enhanced industry standard architecture EISA, weiterentwickelte Industriestandardarchitektur), der lokale VESA-Bus (Video Electronics Standards Association VESA, Standardisierungsverband für Videoelektronik) und der PCI-Bus (peripheral component interconnect PCI, Anschluss von Peripheriekomponenten), der auch als Mezzanin-Bus bekannt ist.
Der Computer 110 umfasst üblicherweise eine Vielzahl computerlesbarer Medien. Als computerlesbares Medium kann ein beliebiges verfügbares Medium verwendet werden, auf das der Computer 110 zugreifen kann. Dazu zählen sowohl flüchtige wie auch nichtflüchtige und sowohl entfernbare wie auch nicht entfernbaren Medien. Zu den Beispielen für computerlesbare Medien zählen Computerspeichermedien und Kommunikationsmedien. Zu den Computerspeichermedien zählen sowohl flüchtige wie auch nichtflüchtige und sowohl entfernbare wie auch nicht entfernbare Medien, die durch ein beliebiges Verfahren oder eine beliebige Technologie zur Speicherung von Information, so beispielsweise für computerlesbare Anweisungen, Datenstrukturen, Programmmodule oder andere Daten, implementiert sind. Zu den Computerspeichermedien zählen unter anderem RAM, ROM, EEPROM, Flash-Speicher oder andere Speichertechnologien, CD-ROM, DVD (digital versatile disk DVD, vielseitig einsetzbare digitale Platte) oder andere optische Speichermedien, Magnetkassetten, Magnetbänder, Magnetplattenspeicher oder andere Magnetspeichervorrichtungen oder ein beliebiges anderes Medium, das zur Speicherung der gewünschten Information verwendet werden kann, und auf das der Computer 110 zugreifen kann. Kommunikationsmedien verkörpern üblicherweise computerlesbare Anweisungen, Datenstrukturen, Programmmodule oder andere Daten in einem modulierten Datensignal, so beispielsweise einer Trägerwelle oder einem anderen Transportmechanismus, und umfassen beliebige Informationsverteilungsmedien. Der Ausdruck „moduliertes Datensignal" bezeichnet ein Signal, bei dem ein oder mehrere Kennwerte derart gesetzt oder verändert sind, dass Information in dem Signal kodiert ist. Zu den Beispielen für Kommunikationsmedien zählen drahtgebundene Medien, so beispielsweise Drahtnetzwerke oder direkt verdrahtete Verbindungen; zu den drahtlosen Medien zählen beispielsweise akustische, HF-basierte, infrarote und andere drahtlose Medien. Kombinationen des Vorgenannten sollen ebenfalls zu den computerlesbaren Medien gerechnet werden.
Der Systemspeicher 130 umfasst Computerspeichermedien in Form von flüchtigen und/oder nichtflüchtigen Speichern, so beispielsweise in Form eines Nurlesespeichers (ROM) 131 und eines Speichers mit beliebigem Zugriff (RAM) 132. Ein grundlegendes Eingabe/-Ausgabesystem (basic input output system BIOS) 133, das die grundlegenden Routinen für den Informationsaustausch zwischen Elementen innerhalb des Computers 110 enthält, so beispielsweise während des Hochfahrens, ist üblicherweise in dem ROM 131 gespeichert. Der RAM 132 umfasst üblicherweise Daten und/oder Programmmodule, auf die unmittelbar zugegriffen werden kann, und/oder auf denen die Verarbeitungseinheit 120 unmittelbar betrieben werden kann. Als Beispiel, das nicht als Beschränkung gedacht ist, zeigt 1 ein Betriebssystem 134, Anwendungsprogramme 135, andere Programmmodule 136 und Programmdaten 137.
Der Computer 110 kann darüber hinaus weitere entfernbare oder nichtentfernbare und flüchtige oder nichtflüchtige Computerspeichermedien umfassen. Aufgeführt sind als Beispiel in 1 ein Festplattenlaufwerk 141, das Daten von nichtentfernbaren nichtflüchtigen Magnetmedien liest oder auf diese schreibt, ein Magnetplattenlaufwerk 151, das Daten von einer entfernbaren nichtflüchtigen Magnetplatte 152 liest oder auf diese schreibt, und ein optisches Plattenlaufwerk 155, das von einer entfernbaren nichtflüchtigen optischen Platte 156, so beispielsweise einer CD-ROM oder einem anderen optischen Medium, liest oder auf diese schreibt. Weitere entfernbare oder nichtentfernbare und flüchtige oder nichtflüchtige Computerspeichermedien, die in als Beispiel angegebenen Betriebsumgebungen verwendet werden können, sind unter anderem Magnetbandkassetten, Flash-Speicherkarten, DVDs, digitale Videobänder, Solid-state-RAMs, Solid- state-ROMs und dergleichen mehr. Das Festplattenlaufwerk 141 ist üblicherweise über eine nichtentfernbare Speicherschnittstelle, so beispielsweise eine Schnittstelle 140, mit dem Systembus 123 verbunden, während das magnetische Plattenlaufwerk 151 und das optische Plattenlaufwerk 155 üblicherweise über eine entfernbare Speicherschnittstelle, so beispielsweise eine Schnittstelle 150, mit dem Systembus 121 verbunden sind.
Die Laufwerke und die damit verbundenen Computerspeichermedien gemäß vorstehender Diskussion sowie gemäß Darstellung in 1 ermöglichen die Speicherung von computerlesbaren Anwendungen, Datenstrukturen, Programmmodulen und anderen Daten für den Computer 110. In 1 ist das Festplattenlaufwerk 141 beispielsweise als Speicherbetriebssystem 144, Anwendungsprogramme 145, andere Programmmodule 146 und Programmdaten 147 dargestellt. Man beachte, dass diese Komponenten mit dem Betriebssystem 134, den Anwendungsprogrammen 135, den anderen Programmmodulen 136 und den Programmdaten 137 entweder gleich oder auch von diesen verschieden sein können. Das Betriebssystem 144, die Anwendungsprogramme 145, die weiteren Programmmodule 146 und die Programmdaten 147 sind hier mit verschiedenen Bezugszeichen versehen, um auszudrücken, dass es sich hierbei um verschiedene Kopien handelt.
Ein Anwender kann Befehle und Informationen in den Computer 110 über Eingabevorrichtungen eingeben, so beispielsweise eine Tastatur 162, ein Mikrofon 163, eine Zeigevorrichtung 161, so beispielsweise eine Maus, einen Trackball oder eine berührungsempfindliche Platte (Touchpad). Weitere Eingabevorrichtungen (nicht gezeigt) umfassen einen Joystick, ein Gamepad, eine Satellitenschüssel, einen Scanner und dergleichen. Diese und weitere Eingabevorrichtungen sind oftmals mit der Verarbeitungseinheit 120 über eine Anwendereingabeschnittstelle 160 verbunden, die mit dem Systembus gekoppelt ist, jedoch auch durch eine andere Schnittstelle und andere Busstrukturen, so beispielsweise einen Parallelport, einen Gameport oder einen universellen seriellen Bus (universal serial bus USB) angeschlossen sein kann. Ein Bildschirm 191 oder eine andere Art von Anzeigevorrichtung ist darüber hinaus mit dem Systembus 121 über eine Schnittstelle, so beispielsweise eine Videoschnittstelle 190, verbunden. Zusätzlich zu dem Bildschirm können Computer auch weitere Peripherieausgabevorrichtungen enthalten, so beispielsweise Lautsprecher 197 und Drucker 196, die über eine Ausgabeperipherieschnittstelle 195 angeschlossen sein können.
Der Computer 110 kann in einer vernetzten Umgebung unter Verwendung logischer Verbindungen mit einem oder mehreren entfernt angeordneten Computern, so beispielsweise dem entfernt angeordneten Computer 180, betrieben werden. Der entfernt angeordnete Computer 180 kann ein Personalcomputer, ein Handgerät, ein Server, ein Router, ein Netzwerk-PC, ein Peer-Gerät oder ein anderer gängiger Netzwerkknoten sein und umfasst typischerweise zahlreiche oder sämtliche vorstehend im Zusammenhang mit dem Computer 110 beschriebenen Elemente. Die in 1 dargestellten logischen Verbindungen umfassen ein Ortsbereichsnetzwerk (local area network LAN) 171 und ein Großbereichsnetzwerk (wide area network WAN) 173, können jedoch auch andere Netzwerke umfassen. Derartige Netzwerkumgebungen sind in Büros, unternehmensweiten Computernetzwerken, Intranets und dem Internet weit verbreitet.
Bei Verwendung in einer LAN-Netzwerkumgebung ist der Computer 110 mit dem LAN 171 über eine Netzwerkschnittstelle oder einen Adapter 170 verbunden. Bei Verwendung in einer WAN-Netzwerkumgebung umfasst der Computer 110 üblicherweise ein Modem 172 oder eine andere Einrichtung zur Vornahme von Datenaustauschvorgängen über das WAN 173, so beispielsweise das Internet. Das Modem 172, das intern oder extern sein kann, kann mit dem Systembus 121 über die Anwendereingabeschnittstelle 160 oder einen anderen geeigneten Mechanismus verbunden sein. In einer vernetzten Umgebung können Programmmodule, die im Zusammenhang mit dem Computer 110 dargestellt sind, oder auch Teile hiervon in der entfernt angeordneten Speicherablagevorrichtung abgelegt sein. 1 zeigt unter anderem entfernt angeordnete Anwendungsprogramme 185 als in dem entfernt angeordneten Computer 180 befindlich. Es ist einsichtig, dass die gezeigten Netzwerkverbindungen lediglich Beispiele darstellen und andere Einrichtungen zur Verwirklichung einer Datenaustauschverbindung zwischen den Computern verwendet werden können.
C. Übersicht über das Textverarbeitungssystem
2 ist ein Blockdiagramm eines Textverarbeitungssystems 200 entsprechend einem Ausführungsbeispiel für eine Umgebung der vorliegenden Erfindung. Das Textverarbeitungssystem 200 umfasst eine linguistische Analysekomponente 202 und eine Normalisierung einer einer semantischen Analysekomponente 204 zugeführten DRS. Die vorliegende Erfindung betrifft die Normalisierung einer der semantischen Analysekomponente 204 zugeführten DRS und die Datenstruktur der normalisierten DRS, wird jedoch aus Gründen der Einfachheit im Kontext des Systems 200 beschrieben.
Bei dem System 200 wird eine Textfolge (textual string) 206 der linguistischen Analysekomponente 202 zugeführt. Die Folge 206 ist beispielhalber eine Aussage, wobei jedoch eine beliebige andere Art von Eingabe in natürlicher Sprache vorliegen kann, sofern sie in Text umgewandelt worden ist. Die linguistische Analysekomponente 202 analysiert die Eingabefolge 206 und erzeugt eine Analyse (parse) hiervon, die bei einem als Beispiel angegebenen Ausführungsbeispiel eine UDRS, einen Syntaxanalysebaum, eine logische Form, eine tokenversehene Folge und einen Satz namenartiger Entitäten enthält. Jede dieser Datenstrukturen ist bekannt und wird daher nur kurz erläutert. Die linguistische Analysekomponente 202 kann eine Vielzahl verschiedener Analysen für jede gegebene Texteingabefolge 206 ausgeben, die nach dem Prinzip „das Beste zuerst" aufgereiht sind.
Die UDRS ist eine linguistische Struktur, die von der linguistischen Analysekomponente 202 ausgegeben wird, und die später noch im Zusammenhang mit 5 detailliert erläutert wird. Der syntaktische Analysebaum und die logischen Formgraphen sind darüber hinaus herkömmliche Abhängigkeits- und Graphstrukturen, die bei der Verarbeitung natürlicher Sprache in der linguistischen Analysekomponente 202 erzeugt werden. Der syntaktische Analysebaum und die logischen Formen werden detailliert in dem US-Patent mit der Nummer 5,995,922 von Penteroudakis et al. beschrieben, das am 30. November 1999 erteilt worden ist. Die tokenversehene Folge ist ebenfalls geläufig und wird aus der Eingabefolge 206 erzeugt. Ein beliebiger Tokenausstatter (tokenizer), der dafür ausgelegt ist, die Eingabefolge 206 in ihre Komponenten aufzuspalten und die Tokens zu etikettieren, kann verwendet werden, um die tokenversehene Folge zu erzeugen. Namenartige Entitäten sind Entitäten, so beispielsweise Eigennamen, die als zusammengehörige Einheit erkannt werden sollen. Obwohl namenartige Entitäten aus sehr verschiedenartigen Bereichen stammen können, entsprechen sie doch hauptsächlich Nominalphrasen.
Obwohl nur einige der genannten Elemente der Analyse notwendigerweise für die semantische Analysekomponente 204 bereitgestellt werden können, werden sie bei einem als Beispiel angegebenen Ausführungsbeispiel von der linguistischen Analysekomponente 202 erzeugt (oder ermittelt) und (als Teile der Analyse der Folge 206) für die semantische Analysekomponente 204 bereitgestellt.
Die semantische Analysekomponente 204 empfängt als Eingabe die Analyse von der syntaktischen Analysekomponente 202, ein Anwendungsschema und einen Satz seman tischer Abbildungsregeln. Auf Basis dieser Eingaben stellt die semantische Analysekomponente 204 als Ausgang eine oder mehrere SemDRS'en bereit, die die von der Eingabefolge angegebene Aussage in Form eines Entität-Relations-Modells eines nichtlinguistischen Bereiches (beispielsweise in Form eines Anwendungsschemas) darstellen.
Das Anwendungsschema und die semantischen Abbildungsregeln werden in vorliegender Offenbarung noch eingehend beschrieben. Es sei jedoch kurz bemerkt, dass das Anwendungsschema beispielsweise von einem Anwendungsentwickler verfasst sein kann. Das Anwendungsschema ist ein Modell der Fähigkeiten und des Verhaltens der Anwendung entsprechend dem Entität-Relations-Modell mit einer damit verknüpften Typenhierarchie. Die semantischen Abbildungsregeln können beispielsweise ebenfalls von dem Anwendungsentwickler erstellt werden und stellen eine Relation zwischen Eingabe-UDRS'en und einem Satz von SemDRS-Fragmenten dar. Die linke Seite der semantischen Abbildungsregel passt auf eine spezielle Form der UDRS, wohingegen die rechte Seite SemDRS-Fragmente spezifiziert, die direkt einem Teil des Anwendungsschemas entsprechen. Durch Anwendung der semantischen Abbildungsregeln auf die UDRS und Beibehalten einer Mehrzahl von Abbildungen und anderer Datenstrukturen kann die semantische Analysekomponente 204 eine Gesamt-SemDRS mit einer gewünschten Boxenstruktur erzeugen, die genau dem Anwendungsschema entspricht, und die ebenfalls die Aussage darstellt, die durch die Eingabefolge 206 angegeben ist, sowie die UDRS, die in die semantische Analysekomponente 204 eingegeben worden ist.
D. Die semantische Analyseschicht
1. Architektur
3 ist ein Blockdiagramm, das eine semantische Analysekomponente 204 detailliert darstellt. 3 zeigt, dass die als Beispiel angegebene semantische Analysekomponente 204 einen semantischen Interpretationskontroller (semantic interpretation controller SIC) 210, einen Interpretationsfragmentgenerator (interpretation fragment generator IFG) 212 und einen Interpretationsassembler (interpretation assembler IA) 214 umfasst. Der SIC 210 umfasst einen Dienstaufrufer (service invoker) 216, eine ISS-Erzeugungskomponente (initial search state ISS, Anfangssuchzustand) 218 und einen DRS-Strukturwiederherstellungsgenerator 220 sowie einen Datenspeicher 215, der sämtliche Interpretationenfragmente und damit verknüpften Informationen, die von dem IFG 212 erzeugt worden sind, enthält. Der IFG 212 enthält eine Schemamaschine 222, eine Blurb-UDRS-Verarbeitungsmaschine 224 und eine Unempfindlichkeitsstrategienverarbeitungsmaschine 226. Der IA 214 enthält eine Lösungsmustererzeugungskomponente 228.
Der SIC 210 steuert den Prozess des Erzeugens der Ausgabe-SemDRS-Interpretationen aus Belegmaterial, das durch die linguistische Analyseschicht (linguistischer Analysator 202) bereitgestellt wird. Er verwaltet darüber hinaus Information, die für die verschiedenen Unterkomponenten des semantischen Analysators 204 bereitgestellt werden muss.
Die von Interesse seienden Hauptkomponenten, die dem SIC 210 zugeführt werden, werden nachstehend detailliert beschrieben. Diese Objekte werden anhand eines Beispieles (Beispiel 1) beschrieben, bei dem die Eingabefolge 206 (in 2 gezeigt) folgendermaßen lautet: „Lösche alle E-Mails, die nicht von KD sind (Delete all e-mails not from KD."
2. Eingabe der DRS-Struktur und Normalisierung
5A zeigt eine Eingabe-DRS (oder UDRS) 250, die eine linguistische Analyse der Eingabefolge darstellt. Die UDRS 250 ist eine Darstellung von Entitäten, über die in der Eingabefolge gesprochen wird, sowie der linguistischen Beziehungen, in denen sie in der Eingabefolge stehen. Bei der als Beispiel angegebenen Eingabefolge liegen drei Modellentitäten oder Dinge vor, die diskutiert werden: eine gelöschte Sache, eine genannte Person, nämlich KD, und die Handlung des Löschens. All diese logischen Elemente sind in der Boxenstruktur 250 von 5A gezeigt. Die Boxenstruktur kann als dynamische Anordnung dargestellt werden, wobei jede Unterbox einem Index in der Anordnung entspricht. Man beachte, dass die Indizes in der DRS-Anordnung in der unteren rechten Ecke jeder Box in der Boxenstruktur 250 angezeigt sind. Man beachte zudem, dass die Variable, mit Blick auf die quantifiziert wird (das heißt, die Variable, die mit „Mail" in der Eingabefolge verknüpft ist), als Teil der logischen Struktur umfasst ist.
In der Boxenstruktur 250 von 5A bezeichnet die Variable y die Person KD, die Variable x einen Teil eines elektronischen Briefes (das heißt ein E-Mail) und der Ausdruck from(x, y) stellt dar, dass e-mail(x) von der Entität (y) stammt. Die Variable e(x) stellt die Handlung des Löschens dar, während der Ausdruck delete(e, x) angibt, dass die Handlung des Löschens e an e-mail(x) vorgenommen werden soll. Der Pfeil in der Boxenstruktur 250 und die inneren Boxen in der Boxenstruktur 250 stellen dar, dass an sämtli chen x (emails), die den Bedingungen email und „not from" (nicht von) genügen (Man beachte, dass die Negation durch das Tildensymbol in der oberen linken Ecke der Außenseite der Box 5 ausgedrückt wird) die Handlung vorgenommen werden soll. Mit anderen Worten, die Boxenstruktur und der Pfeil geben bei dem spezifischen Beispiel an, dass an sämtlichen E-Mails, die nicht von KD sind, eine Handlung des Löschens vorgenommen werden soll (das heißt, sie sollen gelöscht werden).
DRS-Repräsentation beziehungsweise DRS-Darstellung
Eine allgemeinere und vollständigere Erläuterung der Datenstrukturen, die eine DRS verkörpern, sowie des Verfahrens zur Normalisierung derartiger Strukturen ist von Nutzen. Es wird selbstredend nur ein als Beispiel angegebenes Repräsentations- und Normalisierungsschema besprochen.
Eine DRS kann man sich als einen Behälter für eine oder mehrere Boxen vorstellen. Sei k die Anzahl der Boxen in der DRS, so hat jede Box einen eindeutigen Index, der eine Zahl zwischen 0 und k – 1 darstellt, was als Boxenetikette (box label) bezeichnet wird.
Mit einer Box sind null oder mehr Boxenelemente verknüpft. Sei n die Anzahl der Elemente einer Box, so weist jedes Element einen eindeutigen Index auf, der eine Zahl zwischen 0 und n – 1 ist.
Ein Boxenelement kann ein Markierungselement, ein Randbedingungselement oder ein logisches Element sein. Ein Markierungselement ist eine Darstellung einer im Diskurs befindlichen Entität. Ein Randbedingungselement weist null oder mehr Argumente und bestimmte Informationen darüber auf, was die Randbedingung ist. Bei einem Ausführungsbeispiel enthält jene Information ein Anhängsel (tag), das die Art der aktuellen Randbedingung angibt, einen Folgenwert (string value) und einen semantischen Wert (semantic value). Ein logisches Element weist analog null oder mehr Argumente und Informationen darüber auf, was der logische Operator ist, der auf jene Argumente angewandt wird.
Ein Boxenelementargument ist eine Markierung, der Index einer Box oder ein Datenwert.
Bei einem Ausführungsbeispiel speichert die DRS einen Vektor aller zugehörigen Boxen und einen Vektor aller zugehörigen Boxenelemente in dem Eintrag für die DRS. Jede Box enthält einen Vektor von Indizes der Elemente, die Teil dieser speziellen Box sind. Hierdurch wird es unaufwändig, die Elemente einer Box zu sortieren, und es wird zudem vereinfacht, sämtliche Boxelemente einer DRS unabhängig davon zu durchlaufen, zu weicher Box sie gehören. Jedes Boxenelement enthält einen Vektor der zugehörigen Boxenelementargumente.
Für eine normalisierte DRS existiert zudem zusätzliche Information, die erhalten bleibt: die Anzahl der unterschiedlichen Markierungen in der DRS, ein Vektor, der jede Markierung mit einer Liste von Paaren eines Boxenindexes und eines Boxenelementindexes innerhalb jener Box verknüpft, und eine Folge, die die normalisierte Folgendarstellung der DRS ist.
Arten von Helfern (Hilfsvariablen)
Eine Markierung ist eine (nicht negative) ganze Zahl. Bei grafischen Darstellungen von DRS'en ist hilfreich, diese ganzen Zahlen auf alphanumerische Folgen abzubilden, wobei die interne Darstellung im angegebenen Beispiel dennoch eine ganze Zahl ist.
Ein Boxenindex beziehungsweise eine Boxenetikette ist eine (nicht negative) ganze Zahl.
Ein BoxArgumentKind-Wert ist entweder null_arg oder arg_marker oder arg_label oder arg_value.
BoxElementKind ist null_elem oder elem_marker oder elem_constraint oder elem_logical.
BoxElementSemKind ist eine Zahl aus einer Anzahl verschiedener Werte. Im Sinne der vorliegenden Offenbarung ist nicht erfindungswesentlich, was diese Werte sind. Eine Implementierung hiervon umfasst null_sem, sem_none, sem_entity, sem_relation, sem_value und sem_dummy.
Ein Datenwert ist ein unspezifizierter Unionstyp. Im Sinne der vorliegenden Offenbarung ist nicht erfindungswesentlich, welcher zugelassene Bereich der Datenwerte vorliegt.
Eine Implementierung hiervon umfasst einen Nullwert, Boole'sche Werte, ganze Zahlen und Folgen. Als Beispiel angegeben sei eine totale Ordnungsrelation < bezüglich der Datenwerte. Bei einer Implementierung geht der Nullwert allen anderen Werten voraus, der Boole'sche Wert geht den ganzen Zahlen und den Folgen voraus, die ganzen Zahlen gehen den Folgen voraus, falsch (false) geht wahr (true) voraus; ganze Zahlen werden auf herkömmliche Weise geordnet, und Folgen werden lexikografisch geordnet.
Ein SemanticNode-Wert ist eine ganze Zahl. Es soll dies ein Index in eine äußere Datenstruktur sein, die einen semantischen Bereich darstellt.
Darstellung von Boxenelementargumenten
Ein Boxenelementargument wird durch einen Eintrag mit den nachfolgenden Feldern dargestellt:

• ein BoxArgumentKind-Wert m_kind.
• eine ganze Zahl m_id.
• ein Datenwert m_data.

Wird ein Boxenelementargument erzeugt, so wird m kind gesetzt. Handelt es sich um arg_maker oder arg_label, dann wird m_id ebenfalls gesetzt. Handelt es sich um arg_value, dann wird m_data ebenfalls gesetzt.
Eine effiziente und optionale Implementierung kann über die m_id- und m_data-Felder gelegt werden, da diese niemals gleichzeitig verwendet werden.
Operationen an Boxenelementargumenten
Sei X ein Boxenelementargument.

• x.kind() bezieht sich auf das x.m_kind-Feld.
• x.marker() bezieht sich auf das x.m_id-Feld und kann verwendet werden, wenn x.m_kind gleich arg_marker ist.
• x.label() bezieht sich auf das x.m_id-Feld und kann verwendet werden, wenn x.m_kind gleich arg_label ist.
• x.data() bezieht sich auf das x.m_id-Feld und kann verwendet werden, wenn x.m_kind gleich arg_value ist.
• Vergleichsoperatoren <_a und <_b können ebenfalls verwendet werden und werden nachstehend noch beschrieben.

Darstellung von Boxenelementen
Ein Boxenelement wird durch einen Eintrag mit den nachfolgenden Feldern dargestellt:

• ein BoxElementKind-Wert m_kind.
• ein BoxElementSemKind-Wert m_sem_kind.
• eine Folge m_ward.
• ein SemanticNode-Wert m_hnode.
• eine ganze Zahl m_number_of_args.
• ein Vektor m_args von Boxenelementargumenten, deren Länge durch m_number_of_args_gegeben ist.

Wird ein Boxenelementargument erzeugt, so muss m kind stets gesetzt sein.

• Ist m_kind gleich elem_marker, so ist m_number_of_args gleich 1 und m_args[0] ein Argument derart, dass m_args[0].kind() gleich arg_marker ist.
• Ist m_kind gleich elem_constraint, dann müssen m_sem_kind und m_number_of_args stets gesetzt sein, und m_args muss mit m_number_of_args Argumenten initialisiert werden. In einer als Beispiel angegebenen Implementierung existiert ebenfalls eine Beziehung zwischen m_sem_kind, m_word und m_hnode:
• Ist m_sem_kind gleich sem_none oder sem_value, dann muss m_word mit einer Folge initialisiert werden.
• Ist m_sem kind gleich sem_entity oder sem_relation, dann muss m_hnode mit einem SemanticNode-Wert initialisiert werden.

Eine effiziente und optionale Implementierung kann über die m_word- und m_hnode-Felder gefegt werden, da diese niemals gleichzeitig verwendet werden.
Eine als Beispiel angegebene Implementierung weist zwei zusätzliche Felder auf, die nicht alle an den Normalisierungsoperationen beteiligt sind. Die in diesen Feldern dargestellte Information wird verwendet, wenn die Semantik eines Satzes erstellt wird. Hierzu zählen:

• eine Liste von ganzen Zahlen m_tokens. Diese zeichnet die Tokens (die Position der Tokens) in einem Eingabesatz auf, der von diesem besonderen Boxenelement abgedeckt ist.
• eine Liste von ganzen Zahlen m_token_span. Diese zeichnet die Tokens (die Positionen der Tokens) in einem Eingabesatz auf, der von der gesamten syntaktischen Phrase abgedeckt wird, wovon dies der Kopf ist.

Operationen an Boxenelementen
Sei x ein Boxenelement.

• x.kind() bezieht sich auf das x.m_kind-Feld.
• x.sem_kind() bezieht sich auf das x.m_sem_kind-Feld.
• x.word() bezieht sich auf das x.m_word-Feld und kann verwendet werden, wenn x.m_kind gleich elem_constraint und x.m_sem_kind gleich sem_none oder sem_value ist.
• x.schema_node() bezieht sich auf das x.m_hnode-Feld und kann verwendet werden, wenn x.m_kind gleich elem_constraint und x.m_sem_kind gleich sem_entity oder sem_relation ist.
• x.operator() bezieht sich auf das x.m_word-Feld und kann verwendet werden, wenn x.m_kind gleich elem_logical ist.
• x.number_of_args() bezieht sich auf das x.m_number_of_args-Feld.
• x.arg(i) bezieht sich auf x.m_args[ij mit 0 ≤ i < x.m_number_of_args.
• x.add_arg(y): sei i gleich x.m_number_of_args; setze x.m_args[i] auf das Boxenelementargument y; addiere 1 zu x.m_number_of_args; gib i wieder.
• x.covered_tokens() bezieht sich auf das x.m_tokens-Feld.
• x.phrase_token_span() bezieht sich auf das x.m_token_span-Feld.
• Die Vergleichsoperatoren <_a und <_b, die nachstehend noch erläutert werden, können ebenfalls verwendet werden.

Darstellung von Boxen
Eine Box wird durch einen Eintrag mit den nachfolgenden Feldern dargestellt:

• ein Feld m_ptr_containing_drs, das ein Zeiger auf eine DRS ist.
• eine ganze Zahl m_number_of_elements.
• ein Ganzzahlenvektor m_element_indices, dessen Länge durch m_number_of_elements gegeben ist.

Wird eine Box erzeugt, so wird m_ptr_containing drs mit einem Zeiger auf die DRS initialisiert, in der die Box befindlich ist oder befindlich sein sollte. m_number_of_elements muss ebenfalls initialisiert werden, wobei für jedes i mit 0 ≤ i < m_number_of_elements gilt: m_args[i] muss auf ein Boxenelementargument initialisiert werden.
Operationen an Boxen
Sei x eine Box.

• x.number_of_elements() bezieht sich auf das x.m number_of_elements-Feld.
• x.element_index(i) bezieht sich auf x.m_element_indices[i] mit 0 ≤ i < x.m_number_of_elements.
• x.element(i) bezieht sich auf x.m_ptr_containing_drs→m_elements[x.m_element_indices[i]] mit 0 ≤ i < x.m_number_of_elements.
• x.add_element(y): sei j gleich x.m_ptr_containing_drs→m_number_of_elements; setze x.m_ptr_containing_drs→m_elements[j] gleich dem Boxenelement y; addiere 1 zu x.m_ptr_containing_drs→m_number_of_elements; sei i gleich x.m_number_of_elements; setze x.m_element_indices[i] gleich j; addiere 1 zu x.m_number_of_elements; gib i zurück.
• x.dominates(i) gibt wahr zurück, wenn für einige j mit 0 ≤ j < x.m_number_of_elements gilt: x.element(j).kind() gleich elem_logical oder elem_constraint, und wenn für einige k mit 0 ≤ k < x.element(j).number_of_args() gilt: x.element(j).arg(k).kind() = arg_label und x.element(j).arg(k).label() = i. Andernfalls wird falsch zurückgegeben. Dies bedeutet, dass die Box x (unmittelbar) die Box mit dem Etikett i enthält.
• x.dominates_star(i) gibt wahr zurück, wenn x ein Element enthält, das ein Boxenetikett j in irgendeinem Argument enthält (siehe „dominates") und wo entweder i = j oder x.m_ptr_containing_drs→box(j).dominates_star(i) gilt. Andernfalls wird falsch zurück gegeben. Dies bedeutet, dass die Box x die Box mit dem Etikett i – möglicherweise indirekt – enthält.
• x.retire() setzt x.m_ptr_containing_drs auf einen Nullzeiger. Dies wird als diejenige Box interpretiert, die nicht mehr in Gebrauch ist, was eine nützliche Operation darstellt, wenn eine DRS während der Analyse modifiziert wird.
• X.in_use() gibt wahr zurück, wenn x.m_ptr_containing_drs kein Nullzeiger ist. Andernfalls wird falsch zurückgegeben.
• Siehe auch die Vergleichsoperatoren <_a und <_b im Folgenden.

Darstellung einer DRS
Eine DRS wird durch einen Eintrag mit den nachfolgenden Feldern dargestellt:

• eine ganze Zahl m_number_of_boxes.
• ein Boxenvektor m_boxes, dessen Länge durch m_number_of_boxes gegeben ist. eine ganze Zahl m_number_of_elements.
• ein Boxenelementvektor m_elements, dessen Länge durch m_number_of_elements gegeben ist.
• eine ganze Zahl m_number_of_markers.

Eine normalisierte DRS enthält auch die nachfolgenden Felder:

• ein Vektor m_marker_map von Listen von Paaren ganzer Zahlen, wovon die Länge durch m_number_of_markers gegeben ist.
• eine Folge m_key.

Wird eine DRS erzeugt, so muss m_number_of_boxes auf 1 initialisiert werden, und eine einzelne leere Box muss in m_boxes getan werden. Darüber hinaus müssen m_number_of_elements und m_number_of_markers gleich 0 gesetzt werden.
Operationen an DRS'en
Sei x eine DRS.

• x.number_of_boxes() bezieht sich auf das x.m_number_of_boxes-Feld.
• x.box(i) bezieht sich auf x.m_boxes[i] mit 0 ≤ i < x.m_number_of_boxes.
• x.number_of_elements() bezieht sich auf das x.number_of_elements-Feld.
• x.element(i) bezieht sich auf m_elements[i] mit 0 ≤ i < x.m_number_of_elements.
• x.add_empty_box(): sei i gleich x.m_number_of_boxes; setze x.m_boxes[i] auf eine leere Box; addiere 1 zu x.m_number_of_boxes; gib i zurück.
• x.add_box(y): stelle sicher, dass y.m_ptr_containing_drs die Adresse von x ist; sei i gleich x.m_number_of_boxes; setze x.m_boxes[i] auf y; addiere 1 to x.m_number_of_boxes; gib i zurück.
• x.add_next_marker(i): sei k gleich x.m_number_of_markers; addiere ein Markierungselement für die Markierung k als letztes Element von x.box(i), vergl. „add-element", addiere 1 zu x.m_number_of_markers; gib k zurück.
• x.add_next_marker(i, j): sei k gleich x.m_number_of_markers; addiere ein Markierungselement für die Markierung k als am weitesten rechts liegendes Argument von x.box(i).element(j), vergl. „add_arg"; addiere 1 zu x.m_number_of_markers; gib k zurück.
• x.dominates(i, j): gib x.box(i).dominates(j) zurück.
• x.dominates star(i, j): gib x.box(i).dominates_star(j) zurück.
• x.finalize(): rufe den nachstehend beschriebenen Normalisierungsalgorithmus auf; durchlaufe die Boxen, Elemente und Argumente von x, um einen Folgeschlüssel zu erzeugen, und speichere ihn unter x.m_key; durchlaufe die Boxen, Elemente und Argumente von x und addiere für jedes Auftreten einer Markierung ein Paar (i, j) zu der Liste für jene Markierung bei x.m_marker_map, wobei i der Boxenindex und j der Index des Elementes in jener Box ist, in der die Markierung aufgetreten ist.

DRS-Normalisierungsalgorithmus
Der Normalisierungsalgorithmus modifiziert die interne Darstellung einer gegebenen DRS derart, dass, obwohl diese dieselbe Information enthält, die Markierungen wie auch die Reihenfolgen betreffend die Boxen und Boxenelemente normalisiert werden. Als Beispiel sei die Eingabe für den Algorithmus einer DRS genannt, die ausrangierte Boxen und nichtreferenzierte Boxenelemente enthalten kann, wobei die Abfolge verwendeter Markierungskennungen Lücken aufweisen kann. Die Ausgabe ist eine modifizierte Form einer Eingabe-DRS, wobei die Modifizierung derart erfolgt, dass die Reihenfolge der Boxen und Elemente in den Boxen normalisiert worden ist, was bedeutet, dass die Boxen der DRS wie auch die Elemente jeder Box den nachstehend definierten <_b-Anordnungen genügen. Darüber hinaus existieren keine unbenutzten Boxen oder Boxenelemente mehr, und die Markierungen in der DRS bilden eine ununterbrochene mit 0 beginnende Abfolge.
Eine Anzahl von Annahmen und Begriffen der Terminologie wird nachstehend erläutert. Wird in den nachfolgenden Beschreibungen im Zusammenhang mit der Bestimmung von Sortierreihenfolgen die Wendung „..., dann ist x < y falsch" oder eine sinnähnliche Wendung benutzt, so bedeutet dies, dass das Ergebnis des Vergleiches das angegebene ist, und dass keine weiteren Schritte unternommen werden sollen. Wird hingegen die Wendung „sortiere vector[a ... b] anstelle, um <_z zu genügen" verwendet, so bedeutet dies, dass ein effizienter Sortieralgorithmus (beispielsweise der Quicksort-Algorithmus, siehe C. A. R. Hoare, Quicksort. Computer Journal, 5(1): 10–15, 1962) auf die Elemente vector[a], vector[a + 1], ..., vector[b – 1], vector[b] angewendet werden soll, sodass anschließend bei u < v nicht der Fall auftreten darf, dass vector[v] <_z vector[u] ist. Der als Beispiel angegebene Sortieralgorithmus stellt sicher, dass das Ergebnis nicht die gegebene Reihenfolge verletzt. Ist jedoch die Sortierreihenfolge nicht umfassend, so kann mehr als ein zulässiges Ergebnis existieren.
Man geht davon aus, dass Vektoren beginnend mit 0 indexiert werden, sodass ein Vektor der Größe k gültige Indizes von 0 bis k – 1 aufweist. Wird ein Vektor eingeführt, so wird davon ausgegangen, dass keine Initialisierung seiner Elemente vorgenommen wird, außer dies wird explizit gesagt. Auf ähnliche Weise werden die Elemente einer Liste beginnend mit 0 aufgezählt, weshalb eine Liste mit k Elementen diese in den Positionen von 0 bis k – 1 aufweist.
Ein Markierungsauftretenstripel ist ein Tripel (i, j, k) ganzer Zahlen, wobei i eine Boxenanzahl, j eine Elementanzahl innerhalb jener Box und k eine Argumentposition innerhalb jenes Elementes bezeichnen. Das Tripel bezeichnet das Auftreten einer Markierung in jenem Element oder eines Markierungselementes einer Box, wobei in diesem Fall j und k gleich 0 sind.
Seien ⟨i₁, j₁, k₁⟩ und ⟨i₂, j₂, k₂⟩ Markierungsauftretenstripel. Der Wahrheitsgehalt von ⟨i₁, j₁, k₁⟩ < ⟨i₂, j₂, k₂⟩ (lies: ⟨i₁, j₁, k₁⟩ geht ⟨i₂, j₂, k₂⟩ lexikografisch voraus) lautet folgendermaßen:

• Ist i₁ < i₂, dann ist ⟨i₁, j₁, k₁⟩ < ⟨i₂, j₂, k₂⟩ wahr.
• Ist i₁ = i₂ und j₁ < j₂, dann ist ⟨i₁, j₁, k₁⟩ < ⟨i₂, j₂, k₂⟩ wahr.
• Ist i₁ = i₂ und j₁ = j₂ und k₁ < k₂, dann ist ⟨i₁, j₁, k₁⟩ < ⟨i₂, j₂, k₂⟩ wahr.
• Gilt keine der drei vorgenannten Bedingungen, dann ist ⟨i₁, j₁, k₁⟩ < ⟨i₂, j₂, k₂⟩ falsch.

Seien L₁ und L₂ Markierungsauftretenstripel. Der Wahrheitsgehalt von L₁ < L₂ (lies: L, geht L₂ lexikografisch voraus) ist folgendermaßen definiert: Sei k die größte Zahl derart, dass für jedes i mit 0 ≤ i < k weder t < u, noch u < t gilt, wobei t und u das i-te Element von L₁ beziehungsweise L₂ sind (dann weisen sowohl L₁ wie auch L₂ wenigstens k Elemente auf).

– Ist die Anzahl der Elemente in L₁ gleich k, dann ist L₁ < L₂ falsch.
– Andernfalls gilt: Ist die Anzahl der Elemente in L₂ gleich k, dann ist L₁ < L₂ wahr.
– Andernfalls gilt: L₁ < L₂ ist äquivalent zu t < u, wobei t und u Elemente k von L₁ beziehungsweise L₂ sind.

Eine Abbildung von einem Typ T auf einen Typ U ist eine Datenstruktur, die ein effizientes Nachschlagen von Werten des Typs T ermöglicht und einen entsprechenden Wert des Typs U zurückgibt. Man sagt, dass sie Verknüpfungen t → u enthält, wobei t ein Wert des Typs T und u ein Wert des Typs U ist. Für jedes t des Typs T existiert höchstens eine Verknüpfung t → u.
Ist m eine Abbildung von T nach U, dann ist der Ausdruck m[e], wobei e vom Typ T ist, vom Typ U. Enthält m eine Verknüpfung t → u, und ist der Wert von e gleich t, dann ist der Wert von m[e] gleich u. Enthält m keine Verknüpfung für t, so ist der Wert von m[e] undefiniert. Es gibt zahlreiche bekannte Datenstrukturen zur effizienten Implementierung von Abbildungen, so beispielsweise Rot-Schwarz-Bäume (diskutiert beispielsweise bei „Symmetric binary B-trees: Data structure and maintenance algorithms" von R. Bayer, veröffentlicht bei Acta Informatica, 1: 290–306, 1972) und Hash-Tabellen (diskutiert beispielsweise bei „Sorting and Searching, Vol. 3" von D. E. Knuth, veröffentlicht bei „The Art of Computer Programming", Addison-Wesley, 1973).
Eine Multiabbildung vom Typ T auf den Typ U ähnelt einer Abbildung von T nach U, außer dass sie mehr als eine Verknüpfung t → u für jedes t in T enthalten kann. Eine Multiabbildung von T nach U ähnelt darüber hinaus einer Abbildung von T auf Sätze von Werten U, wobei jedoch keine Unterscheidung zwischen einer Abbildung, die einen leeren Satz mit einem Wert t verknüpft, und einer Abbildung, die keinen Satz mit t verknüpft, getroffen wird.
Die folgenden beiden Anordnungsrelationen zwischen Boxen, nämlich <_a und <_b, werden nunmehr definiert. Sie werden rekursiv im Zusammenhang mit entsprechenden Anordnungsrelationen zwischen Boxenelementen und zwischen Boxenelementargumenten definiert. Aus Gründen der Bequemlichkeit werden diese Anordnungsrelationen ebenfalls als <_a und <_b bezeichnet. Aus dem Kontext ist stets klar, ob Anordnungen bezüglich Boxen, Boxenelementen oder Boxenelementargumenten vorliegen. Werden zwei Boxen, zwei Boxenelemente oder zwei Boxenelementargumente verglichen, so gehören sie stets zur selben DRS. Schließlich sind die Anordnungen <_a und <_b bezüglich der Indizes der Boxen in einer DRS im Zusammenhang mit den Anordnungen bezüglich der Boxen selbst definiert.
•_a bezüglich der Boxenelementargumente
Die Relation <_a zwischen Boxenelementargumenten x und y in einer DRS ist entsprechend der Matrix von Tabelle 1 definiert.
Tabelle 1

(a) Sind x.kind() und y.kind() gleich arg_label, so ist x <_a y gleichwertig zu drs.box(x.label()) <_a drs.box(y.label()).
(b) Sind x.kind() und y.kind() gleich arg_value, so ist x <_a y gleichwertig zu x.data() < y.data(), wobei < die totale Anordnung bezüglich der Datenwerte und <_b bezüglich der Boxenelementargumente ist.

Die Relation <_b zwischen Boxenelementargumenten x und y in einer DRS ist entsprechend der Matrix von Tabelle 2 definiert.
Tabelle 2

(c) Sind x.kind() und y.kind() gleich arg_marker, so ist x <_b y gleichwertig zu x.marker() < y.marker().
(d) Sind x.kind() und y.kind() gleich arg_label, so ist x <_a y gleichwertig zu x.label() < y.label().

Man beachte, dass drs.box(x.label()) <_a drs.box(y.label()) wie unter (a) hätte verwendet werden können. Es ist jedoch bekannt, dass, wann immer <_b angewandt wird, diese Tests gleichwertig sind, und der Ganzzahlenvergleich x.label() < y.label() effizienter ist.
<_a bezüglich der Boxenelemente
Die Relation <_a zwischen Boxenelementen x und y in einer DRS ist entsprechend der Matrix von Tabelle 3 definiert.
Tabelle 3

(e) Sind x.kind() und y.kind() beide gleich elem_constraint oder beide gleich elem_logical, so wird x <_a y durch die nachfolgenden Schritte bestimmt.

Schritt 1: Sei n_x = x.number_of_args() and n_y = y.number_of_args. Ist n_x < n_y, dann ist x <_a y wahr. Ist n_x > n_y, dann ist x <_a y falsch. Andernfalls zum nächsten Schritt übergehen.
Schritt 2: Seien s_x = x.sem_kind() und s_y = y.sem_kind(). Ist s_x < s_y, dann ist x <_a Y wahr. Ist s_x > s_y, dann ist x <_a y falsch. Andernfalls zum nächsten Schritt übergehen.
Schritt 3: Sind s_x und s_y nicht gleich null_sem, no_sem oder value, dann zum nächsten Schritt übergehen. Andernfalls x.word() und y.word() in lexikografischer Ordnung vergleichen. Geht x.word() dem Ausdruck y.word() voraus, dann ist x <_a y wahr. Geht y.word() dem Ausdruck x.word() voraus, dann ist x <_a y falsch. Trifft beides nicht zu, zu Schritt 5 übergehen.
Schritt 4: Sind s_x und s_y nicht Entität oder Relation, zum nächsten Schritt übergehen. Andernfalls x.schema_node() und y.schema_node() vergleichen. Geht x.schema_node() dem Ausdruck y.schema_node() voraus, dann ist x <_a y wahr. Geht y.schema_node() dem Ausdruck x.schema_node() voraus, dann ist x <_a y falsch. Trifft beides nicht zu, zum nächsten Schritt übergehen.
Schritt 5: Es sei bekannt, dass die Boxenelemente x und y dieselbe Anzahl von Argumenten (n_x und n_y, siehe oben) haben. Setze die ganzzahlige Variable i auf 0.
Schritt 6: Ist i = n_x, dann ist x <_a y falsch, Andernfalls seien a und b die Argumente an Position i der Boxenelemente x beziehungsweise y. Ist a <_a b, dann ist x <_a y wahr. Andernfalls gilt: Ist b <_a a, dann ist x <_a y falsch. Andernfalls i um 1 erhöhen und diesen Schritt wiederholen.
<_a bezüglich der Boxenelementkennungen
Die Relation <_a zwischen Boxenelementkennungen i und j in einer DRS wird durch Bestimmen der Relation <_a zwischen den Boxenelementen mit den Kennungen i beziehungsweise j der DRS bestimmt.
<_b bezüglich der Boxenelemente
Die Relation <_b zwischen Boxenelementen x und y in einer DRS ist entsprechend der Matrix von Tabelle 4 definiert.
Tabelle 4

(f) Sind x.kind() und y.kind() gleich elem_marker, so ist x <_b y gleichwertig zu x.marker() < y.marker().
(g) Sind x.kind() und y.kind() beide gleich elem_constraint oder beide gleich elem_loglcal, dann wird x <_b y genau wie unter (e) für x <_a y oben bestimmt, mit der Ausnahme, dass in Schritt 6 der Vergleich zwischen den Boxenelementargumenten a und b unter Verwendung von <_b vorgenommen wird.

<_a bezüglich der Boxen
Die Relation <_a zwischen den Boxen x und y in einer DRS wird durch die nachfolgenden Schritte berechnet.
Schritt 1: Ist y gleich drs.box(0), dann ist x <_a y falsch. Andernfalls gilt: Ist x gleich drs.box(0), dann ist x <_a y wahr. Gilt andernfalls DominatesStr(x, y), dann ist x <_a y wahr. Gilt andernfalls DominatesStar(y, x), dann ist x <_a y falsch. Sei andernfalls n_x und n_y die Anzahl von Elementen in den Boxen x beziehungsweise y, dann setze die ganzzahlige Variable i auf 0 und gehe zum nächsten Schritt über.
Schritt 2: ist i = n_x, dann ist x <_a y falsch. Ist andernfalls i = n_y, dann ist x <_a y wahr. Andernfalls seien a und b das Element i der Boxen x beziehungsweise y. Ist a <_a b, dann ist x <_a y wahr. Andernfalls gilt: Ist b <_a a, dann ist x <_a y falsch. Andernfalls i um 1 erhöhen und diesen Schritt wiederholen.
<_a bezüglich der Boxenkennungen
Die Relation <_a zwischen den Boxenkennungen i und j in einer DRS wird durch Bestimmen der Relation <_a zwischen den Boxen mit den Kennungen i beziehungsweise j der DRS bestimmt.
<_b bezüglich der Boxen
Die Relation <_b zwischen Boxen x und y in einer DRS wird genauso wie bei x <_a y, siehe oben, bestimmt, mit der Ausnahme, dass bei Schritt 6 der Vergleich zwischen den Boxenelementargumenten a und b unter Verwendung von <_b vorgenommen wird.
•_b bezüglich der Boxenkennungen
Die Relation <_b zwischen den Boxenkennungen i und j in einer DRS wird durch Bestimmen der Relation <_b zwischen den Boxen mit den Kennungen i beziehungsweise j der DRS bestimmt.
Eingedenk der vorstehenden Diskussion ist einsichtig, dass die <_a-Anordnung ohne Rücksicht auf die Markierungen sortiert, während die <_b-Anordnung auch unter Berücksichtigung der Markierungen sortiert.
Normalisierungsalgorithmus
Der Normalisierungsalgorithmus kann als mehrere Stufen umfassend beschrieben werden. In der ersten Stufe werden sämtliche unbenutzten Boxen und Boxenelemente aus der DRS gelöscht. In der zweiten Stufe werden die Boxen und die Elemente der Boxen mit einer vorläufigen Anordnung versehen, die die Markierungen ignoriert (Boxen und Boxenelemente, die sich nur bezüglich der Markierungen unterscheiden, werden damit als gleichwertig behandelt). Auf Basis der vorläufigen Anordnung wird eine Anordnung für die Markierungen erstellt, woraufhin die Markierungen in fortlaufender Abfolge um nummeriert werden. Schließlich werden die Boxen und Boxenelemente mit einer endgültigen Anordnung versehen, und zwar auf Basis der vorläufigen Anordnung unter Berücksichtigung der Anordnung der Markierungen. Die Anordnung der Markierungen ist nicht eindeutig bestimmt, es existiert jedoch die brauchbare Eigenschaft, dass unabhängig von der Wahl der zulässigen Markierung das Ergebnis nach der endgültigen Umnummerierung gleich ist.
5B ist ein Flussdiagramm, das darlegt, wie die verschiedenen erzeugten DRS-Strukturen für eine spätere Verarbeitung normalisiert werden. Man beachte, dass die Normalisierung der Eingabe-DRS von der syntaktischen Analysekomponente 202 oder der semantischen Analysekomponente 204 oder auch von einer beliebigen anderen externen Komponente vorgenommen werden kann. Als Beispiel sei angeführt, dass diese von dem SIC 210 in der semantischen Analysekomponente 204 vorgenommen werden kann. Man beachte zudem, dass der Pseudocode für den Prozess, der durch den Algorithmus in 5B gezeigt ist, in Anhang A enthalten ist, wobei in der Beschreibung von 5B auf Anhang A Bezug genommen wird.
Zunächst empfängt die Normalisierungskomponente (unabhängig davon, wo sich diese befindet) die Eingabe-DRS (das heißt, die Anordnung von Boxen). Dies ist durch den Block 251 angegeben.
Es kann der Fall auftreten, dass während der Erzeugung der Eingabe-DRS Boxen oder Boxenelemente, die nicht genutzt werden, miteingeschlossen werden. Daher werden die unbenutzten Boxen und Boxenelemente in der DRS identifiziert und, wie durch den Block 253 angegeben ist, gelöscht. Die verbleibenden Boxen werden anschließend, wie durch 255 angegeben ist, umnummeriert. Das Löschen der unbenutzten Boxen und das Umnummerieren dieser Boxen ist in Schritt 1 von Anhang A dargestellt.
Anschließend wird eine vorläufige Sortierung der Boxen auf Basis der Boxenindizes vorgenommen. Dies ist in 5B durch die Blöcke 257 angegeben.
Nachdem die Boxen auf Basis ihrer Indizes vorläufig sortiert worden sind, wird eine vorläufige Sortierung der Boxenelemente unter Nichtberücksichtigung der Markierungen in den Boxenelementen vorgenommen. Diese vorläufige Sortierung wird in Schritten 3 bis 7 von Anhang A vorgenommen und durch Block 259 in 5B angegeben. Insbesondere nimmt der Algorithmus in Schritt 3 eine <_a-Sortierung bezüglich der Boxenelementken nungen vor. Die Boxenelemente werden anschließend entsprechend der Sortierung umgeordnet, und es wird Speicherplatz, der vorher von den Boxen und den unbenutzten Boxen eingenommen wurde, freigegeben. Dies wird in Schritten 4 und 5 von Anhang A vorgenommen. Sobald die Boxenelemente sortiert und umgeordnet worden sind, werden die Boxen selbst derart aktualisiert, dass Sie erneut die richtigen Boxenelemente aufweisen. Dies wird in Schritt 6 des Algorithmus von Anhang A vorgenommen. Auf ähnliche Weise werden anschließend die Boxenelemente selbst derart aktualisiert, dass sie sich erneut auf die richtigen Boxen beziehen. Dies wird in Schritt 7 des Algorithmus vorgenommen.
Es ist ersichtlich, dass nach den ersten sieben Schritten des Algorithmus von Anhang A und nach der vorläufigen Sortierung der Boxen auf Basis der Boxenindizes, wie in Block 257 angegeben, sowie der vorläufigen Sortierung der Boxenelemente (unter Nichtberücksichtigung der Markierungen), wie in Block 259 von 5B dargestellt ist, die Boxen und Elemente vollständig unter Nichtberücksichtigung der Markierungen sortiert sind. Dies bedeutet, dass jede der Boxen und jedes der Boxenelemente entsprechend der Sortierung durch den vorstehend erläuterten Vergleichsalgorithmus sortiert worden ist. Die einzigen Boxen und Boxenelemente, die nicht vollständig sortiert worden sind, sind diejenigen, die sich nur bezüglich ihrer Markierungen unterscheiden. Derartige Boxen und Boxenelemente werden an diesem Punkt des Algorithmus gleichwertig angeordnet.
Schritte 8 bis 11 werden anschließend mittels eines Durchlaufens der DRS zur Ermittlung von Information und Datenstrukturen, die zur Vornahme einer endgültigen Sortierung notwendig sind, ausgeführt. Bei der endgültigen Sortierung werden nicht nur die Boxen und Boxenelemente entsprechend den Indizes sortiert, sondern es erfolgt auch eine Sortierung bezüglich der Markierungen. Der Algorithmus beginnt damit, den Markierungen eindeutige fortlaufende Werte zuzuweisen. Gleichwohl ist während dieses Prozesses wünschenswert, dass Identitäten zwischen Markierungen und Elementen oder Boxen nicht verloren gehen. Daher werden bei Schritten 8 und 9 Abbildungen aufgezeichnet, die diese Identitäten beibehalten.
Bei Schritt 8 werden Abbildungen von den Markierungen auf Listen von Markierungsauftretenstripeln für Markierungselemente, Randbedingungen und logische Elemente erzeugt. Es ist ersichtlich, dass die Anordnung, in der die Markierungsauftretenstripel der Liste in der Abbildung hinzugefügt werden, sicherstellt, dass jede Liste bezüglich der Tripel lexikografisch angeordnet ist.
Schritt 9 erzeugt umgekehrte Abbildungen von den Listen der Markierungsauftretenstripel auf die Markierungen, sodass eine Anordnung für die Markierungen erzeugt wird. Die Erzeugung der Abbildungen ist in 5B durch Block 261 angegeben.
Sobald die Abbildungen zur Beibehaltung der Identitäten erzeugt worden sind, werden den Markierungen neue Markierungswerte zugewiesen, und es werden die Elemente mit den neuen Markierungswerten aktualisiert. Dies ist in 5B in Block 263 angegeben. Die Zuweisung neuer Markierungswerte für die Markierungen wird in Schritt 7 von Anhang A vorgenommen. Die Aktualisierung der Elemente mit den neuen Markierungswerten (und damit die Umnummerierung dieser in fortlaufender Abfolge) wird in Schritt 11 von Anhang A vorgenommen.
Schließlich wird eine endgültige Sortierung auf Basis der vorläufigen Sortierung wie auch der Anordnung der Markierungen vorgenommen. Dies ist in 5B in Block 265 und darüber hinaus in Schritt 12 von Anhang A angegeben. Die Ausgabe ist eine DRS, die derart modifiziert ist, dass die Anordnung der Boxen sowie der Elemente in den Boxen normalisiert ist. Dies bedeutet, dass die Boxen der DRS wie auch die Elemente jeder Box den vorstehend festgelegten <_b-Anordnungen genügen. Darüber hinaus existieren keine unbenutzten Boxen oder Boxenelemente mehr, und die Markierungen der DRS bilden eine mit 0 beginnende ununterbrochene Abfolge.
Schlüsselfolge
Es kann eine Prozedur implementiert werden, die auf Grundlage einer DRS in dieser Repräsentationsstruktur eine Folge ausgibt, die in einer Eins-zu-Eins-Beziehung zu der DRS steht. Für eine normalisierte DRS ist diese Folge entsprechend normalisiert. Es kann eine umgekehrte Prozedur implementiert werden, die auf Grundlage einer Normalfolgenrepräsentation einer DRS eine DRS in der vorliegenden Repräsentationsstruktur erzeugt, die von der ursprünglichen DRS nicht zu unterscheiden ist. Gegenüber dem Vorliegen einer serialisierten Normalrepräsentation hat dies unter anderem die nachfolgenden Vorteile.

• Die Folgen können dauerhaft in Dateien oder Datenbanken abgelegt werden, oder sie können über serielle Streams gesendet werden. Der Leser einer derartigen Datei oder Datenbank oder der Empfänger eines derartigen Streams kann die ursprüngliche normalisierte DRS wiedererzeugen.
• Die Folgen können als Schlüssel in einem Datenbanksystem verwendet werden.
• Die Folgen können unter Verwendung standardisierter Folgenhilfsprogramme effizient bezüglich Gleichwertigkeit (und anderer geeigneter Relationen) verglichen werden.

Eine derartige Prozedur beinhaltet das rekursive Durchlaufenen der DRS sowie die Erzeugung einer Folge, die die vorgefundenen Boxen, Boxenelemente und Boxenelementargumente kompakt und eindeutig beschreibt.
Die umgekehrte Prozedur umfasst das Analysieren (Parsen) einer derartigen Folge und die Box für Box, Boxenelement für Boxenelement und Boxenelementargument für Boxenelementargument erfolgende Wiederherstellung der DRS.
3. Anwendungsschema
6 zeigt ein Schema 300, das für das vorliegende Beispiel geeignet ist. Das Schema 300 ist ein Graph von Entitäten und Relationen, wobei die Entitäten in Kreisen (oder Ovalen) und die Relationen in Boxen dargestellt sind. Das Schema 300 zeigt beispielsweise, dass die Anwendung das Senden und Löschen verschiedener spezifischer E-Mail-Nachrichten unterstützt. Dies wird dargestellt, da die E-Mail-Objekte das Ziel von „DeleteAct" oder „InitiateEmailAct" sein können.
Darüber hinaus können derartige E-Mail-Nachrichten Sender oder Empfänger aufweisen, die durch eine „Person" bezeichnet sind, die einen „Namen" aufweist, der durch eine Buchstabenfolge angegeben ist. Die E-Mail-Objekte können auch anhand der Zeit, zu der sie gesendet wurden, sowie anhand ihres Inhaltes, der wiederum ebenfalls durch eine Zeichenfolge dargestellt ist, spezifiziert werden.
Die Aufgabe der semantischen Analysekomponente 204 der vorliegenden Erfindung besteht darin, die Analyse (Parse) zu empfangen (die die in 5 gezeigte UDRS-Boxenstruktur aufweist) und diese exakt mittels des in 6 gezeigten Anwendungsschemas 300 zu interpretieren. Diese Interpretation kann anschließend an die Anwendung weitergegeben werden, da sie dort „verstanden" wird. Hierfür wendet die semantische Analysekomponente 204 zunächst semantische Abbildungsregeln auf die UDRS an.
4. Semantische Abbildung
Eine semantische Abbildung ist eine Relation zwischen einem Satz von UDRS'en und einem Satz von SemDRS-Fragmenten. Eine semantische Abbildungsregel ist ein Ausdruck mit einer linken Seite, die auf Unterteile von UDRS'en bestimmter Form passt, und einer rechten Seite, die ein bestimmtes SemDRS-Fragment spezifiziert. Zusätzlich enthält die Regel eine Entsprechung dahingehend, dass für jede Position auf der linken Seite, die auf eine Markierung passt, eine entsprechende rechte Position identifiziert wird, außer es wird einfach die Variable eliminiert. Syntaktisch kann diese Entsprechung durch Verwendung derselben Markierungen auf beiden Seiten der Abbildungsregel einfach dargestellt werden. Die semantische Abbildungsregel kann also zum Umschreiben einer UDRS auf einen Satz von SemDRS-Fragmenten verwendet werden.
Ein Satz semantischer Abbildungsregeln bezeichnet die semantische Abbildung derart, dass für dieselbe Regel in dem Satz für den Fall, dass die linke Seite auf einen Unterteil der UDRS passt, und die rechte Seite das SemDRS-Fragment mit den entsprechenden aus der UDRS ersetzten Variablen ist, eine Komponente der semantischen Abbildung die Beziehung zwischen der Eingabe-UDRS auf der linken Seite und dem SemDRS-Fragment auf der rechten Seite ist. Selbstverständlich ist für den Fall, dass mehr als eine Regel in einem Satz auf eine UDRS Anwendung findet, mehr als ein mögliches Ergebnis der Anwendung der durch den Regelsatz festgelegten semantischen Abbildungen gegeben.
Bei einem als Beispiel angegebenen Ausführungsbeispiel weisen zahlreiche semantische Abbildungsregeln die Form [|word(x)]→[|type(x)] auf, so beispielsweise die nachfolgenden Regeln.

[|message(x)] → [|Maillterm(x)]

[|email(x)] → [|Maillterm(x)]

[|email(e, x, y)] → [|InitiateEmailACtion(e)]
Bei einem als Beispiel angegebenen Ausführungsbeispiel kann ein allgemeiner Fall einer semantischen Abbildungsregel auf eine willkürliche UDRS auf der linken Seite passen. So sucht beispielsweise der allgemeine Fall nach einer bestimmten Konfiguration von Boxen und logischen Operatoren. Die rechte Seite kann ebenfalls eine willkürliche SemDRS spezifizieren, wobei erneut beispielhalber (gegebenenfalls verschachtelte) Bo xen und logische Operatoren enthalten sind. Schließlich ist die Variablenentsprechung beispielhalber allgemein genug, damit eine Anzahl von Auftretensfällen von Markierungen von der linken Seite auf die rechte Seite wechseln können. Beispiele noch allgemeinerer Regeln lauten wie folgt.

[|make(e, x, [font(y), bold(y)]) → [|AlterFont(e), Alters(e, z), HasNewProperty(z, y), Boldface(y)]

[|~[save(e, x, y], mail(y)] → [|DeleteMailAction(e), HasTarget(e, y), Mailltem(y)]
Wie diese Beispiele verdeutlichen, ist bisweilen der Versuch wünschenswert, bei gegebenen semantischen Abbildungsregeln auf mehr als ein Wort zu passen. Es treten zwei Fälle auf, die im Beispiel leicht unterschiedlich behandelt werden.
Erstens können semantische Abbildungsregeln für bestimmte Abfolgen von Worten, die möglicherweise bezüglich dieses Falles, Stammes und dergleichen mehr normalisiert worden sind, erzeugt werden. Dies gilt für Worte wie beispielsweise „Hotdog" oder den Eigennamen einer Person, der einen Vornamen und einen Nachnamen umfasst.
Zweitens können semantische Abbildungsregeln für Worte erzeugt werden, die in einer bestimmten syntaktischen Konfiguration auftreten, wie in den beiden unmittelbar vorhergehenden Beispielen. Im ersten Fall ist für den Fall, dass die Abfolge von Worten als Multiwortentität in einem Lexikon auftritt, eine lexikalische Einheit gegeben, und es wird die semantische Abbildung auf das Einzelwort entsprechend angewendet. Ist die Abfolge von Worten eine namenartige Entität, so behandeln die semantischen Regeln diese ebenfalls als eine Einheit.
Die semantischen Abbildungsregeln können beispielhalber vom Entwickler der Anwendung verfasst werden, oder sie können auf Basis einer ausreichenden Vorgabe von dem Anwender der Entwicklung und durch Ableiten derselben aus dem Schema erstellt werden.
E. Allgemeiner Betrieb der semantischen Analyseschicht
Die von dem SIC 210 empfangene Information wird dem IFG 212 gänzlich zur Verfügung gestellt. Die semantische Abbildung und das Anwendungsschema werden zusammen mit den Daten in dem Datenspeicher 215 dem IA 214 zur Verfügung gestellt. Um die Dienste des IFG 212 (und der zugehörigen verschiedenen Unterkomponenten) und des IA 214 (und der zugehörigen verschiedenen Unterkomponenten) aufzurufen, umfasst der SIC 210 einen Dienstaufrufer (service invoker) 216, der die Daten mit Blick auf die verschiedenen Komponenten in dem System verwaltet. Auf Basis dieser Information erzeugt der IFG 212 Interpretationsfragmente, die dem SIC 210 zur Verfügung gestellt und anschließend in dem Datenspeicher 215 gespeichert werden. Es gibt drei verschiedene Grundtypen von Interpretationsfragmenten, nämlich diejenigen, die durch die Anwendung der semantischen Abbildungsregeln auf die UDRS erzeugt worden sind, diejenigen, die durch die Interpretation der Elemente in der Eingabe, so beispielsweise einer Folge, was nachstehend als Blurbs bezeichnet wird, erzeugt worden sind, und diejenigen, die durch Unempfindlichkeitsstrategien erzeugt worden sind. Der Mechanismus, durch den der erste Typ von Interpretationsfragmenten erzeugt wird, kann beispielhalber weitgehend sprachunabhängig sein, während die letzteren beiden beispielhalber durch sprachabhängige Argumentation bezüglich ihrer tokenversehenen Folge, des Syntaxanalysebaumes, der logischen Form und der namenartigen Entitäten erzeugt werden können. Die Interpretationsfragmente werden über eine Schnittstelle, die der SIC 210 für den IFG 212 bereitstellt, in den Datenspeicher 215 rückgeschrieben.
Auf Basis der Interpretationsfragmente erzeugt der SIC Muster und Anfangssuchzustände in der ISS-Erzeugungskomponente 218. Die Anfangssuchzustände entsprechen den teilweise vollständigen SemDRS-Strukturen, wobei die logische Struktur und die Boxenstruktur entfernt worden sind. Die Anfangssuchzustände zusammen mit den Präferenzen dahingehend, wie die Interpretationsfragmente (oder Muster), die in den Anfangssuchzuständen verkörpert sind, zu assemblieren beziehungsweise zusammenzufügen sind, werden dem IA 214 zur Verfügung gestellt.
Der IA 214 gibt einen Satz von Lösungsmustern aus. Die Lösungsmuster werden in vollständig interpretierte SemDRS'en umgewandelt, indem ihre logische Struktur und ihre Boxenstruktur, soweit möglich, wiederhergestellt werden. Dies erfolgt durch den DRS-Strukturwiederherstellungsgenerator 220, wobei die vollständig interpretierten SemDRS'en von dem SIC 210 ausgegeben werden.
F. Detaillierter Betrieb der semantischen Analyseschicht
4 zeigt ein Flussdiagramm, das den Gesamtdatenfluss in der semantischen Analysekomponente 204 eingehend darstellt. Viele dieser Blöcke werden detailliert in späterer in der Detailbeschreibung noch beschriebenen Figuren erklärt.
Der SIC 210 empfängt zunächst die Analyse (Parse), das Anwendungsschema und die semantischen Abbildungsregeln und initialisiert den Datenspeicher 215, der innerhalb des SIC 210 erhalten ist. Dies ist in dem Block 320 in 4 angegeben. Der Datenspeicher 215 umfasst die UDRS, die eine Aufzeichnung der logischen Struktur und der Boxenstruktur der Eingabe-DRS ist, und wird aktualisiert, wann immer eine semantische Abbildungsregel eine Änderung in dieser Struktur lizenziert. Die Datenstrukturen enthalten zudem:

• eine Tokenliste, die eine Liste von Tokens in der ursprünglichen Abfolge ist;
• einen Satz von SemDRS-Fragmenten mit den Tokens, die hierdurch abgedeckt werden, den zugehörigen damit verknüpften Kosten und der ursprünglichen Box, in die sie verbracht werden sollen, wenn die logische Struktur und die Boxenstruktur der DRS wiederhergestellt wird. Diese Fragmente werden alle von den verschiedenen Unterkomponenten des IFG 212 erzeugt. Die SemDRS-Fragmente werden die Kernelemente der Anfangssuchzustände, die in den IA 214 eingegeben werden;
• Präferenzen (Vorlieben), die Anweisungen dahingehend darstellen, wie Muster in den Anfangssuchzuständen zusammengefügt werden sollen, damit Lösungsmuster ermittelt werden können.

Der Datenspeicher 215 stellt die notwendigen Schnittstellen für die anderen Komponenten in dem System bereit, damit diese auf die Daten in dem Datenspeicher 215 zugreifen, Daten hinzufügen oder aktualisieren können.
Sobald der Datenspeicher 215 initialisiert ist, stellt der Dienstaufrufer 216 in dem SIC 210 den Eingabesatz und die semantischen Abbildungsregeln für den IFG 212 bereit und ruft die Dienste des IFG 212 auf. Dies ist in 4 in Block 322 angegeben.
Anschließend wendet die semantische UDRS-Abbildungsverarbeitungsmaschine 222 in dem IFG 212 alle anwendbaren semantischen Abbildungsregeln auf die UDRS an. Dies ist in Block 324 angegeben. Man beachte, dass diese Regeln zum Zeitpunkt der Kompilierung erzeugt werden können, oder dass sie aus anderen Regeln und dem Schema zum Zeitpunkt des Ablaufens erzeugt werden können. Das Ergebnis der Anwendung der semantischen Abbildungsregeln ist ein Satz von Interpretationsfragmenten, der eine Abbildung zwischen einem Satz von UDRS-Boxenelementen und einem Satz von SemDRS-Boxenelementen spezifiziert. Die Token-Abdeckung dieser Interpretationenfragmente ist als Satz von Tokens in der Eingabefolge in Entsprechung zu dem passenden UDRS-Boxenelement definiert. Die Interpretationenfragmente mit ihrer Token-Abdeckung und den verknüpften Kosten werden an den Datenspeicher 215 gesendet und gespeichert. Dies ist in 4 in Block 326 angegeben. Man beachte zudem, dass selbstredend auch mehrere Regeln auf denselben Teil der UDRS angewandt werden können.
Information in der UDRS kann zudem auch als „Blurb" interpretiert werden. Das Vorhandensein von Blurbs wird durch die Ergebnisse der Interpretation der Eingabe-DRS (oder UDRS) nahegelegt, woraufhin der SIC 210 bestimmt, ob die Blurbs durch den IFG 212 nahegelegt werden. Dies ist in dem Block 332 angegeben. Ist dem so, so ruft der Dienstaufrufer 216 die Blurb-UDRS-Verarbeitungsmaschine 224 auf, die die Blurb-Verarbeitung auf Basis des Syntaxanalysebaumes oder der logischen Formen vornimmt, und die die Interpretationenfragmente auf Basis jener Blurb-Verarbeitung erzeugt. Die resultierenden Interpretationenfragmente nebst zugehöriger Token-Abdeckung und Kosten werden dem IFS 215, wie in Block 334 angegeben ist, zur Verfügung gestellt.
Anschließend bestimmt der SIC 210, ob Unempfindlichkeitsstrategien verwendet werden sollen. Unempfindlichkeitsstrategien werden detailliert anhand 11 beschrieben. Sie umfassen grundsätzlich die Anwendung von Umschreibregeln auf Folgenbasis weniger auf UDRS-Boxenelemente sowie das Ausführen einer weiteren Blurb-Verarbeitung. Das Bestimmen, ob Unempfindlichkeitsstrategien verwendet werden sollen, ist in Block 340 angegeben.
Ist dem so, so ruft der Dienstaufrufer 216 die Unempfindlichkeitsstrategienverarbeitungsmaschine 226 in dem IFG 212 auf, wo die Interpretationsfragmente auf Basis der Unempfindlichkeitsstrategienverarbeitung erzeugt werden. Diese Verarbeitung umfasst das Untersuchen des syntaktischen Analysebaumes, der logischen Form und der namenartigen Entitäten zum Zwecke der Identifizierung von Objekten, die nicht in der UDRS sind, sowie das Erzeugen von Interpretationsfragmenten aus diesen. Die Interpretationsfragmente werden erzeugt, und die zugehörige Token-Abdeckung sowie die Kosten werden an den Datenspeicher 215, der in Block 342 angegeben ist, gesendet.
Der SIC 210 aktualisiert die Daten, die in dem Datenspeicher 215 gespeichert sind, und wandelt die Interpretationsfragmente in zusätzliche Muster, wie in Block 346 angegeben ist, um.
Die derart erzeugten Muster werden durch die ISS-Erzeugungskomponente 218 des SIC 210 zu Anfangssuchzuständen gepackt. Dies ist in Block 348 angegeben. Die Anfangssuchzustände werden derart gepackt, dass jedes Token der Eingabefolge durch ein und nur ein Muster abgedeckt wird. Formal umfasst der Anfangssuchzustand einen Satz von Mustern und Präferenzen, durch den beschränkend vorgegeben ist, wie Muster assembliert beziehungsweise zusammengefügt werden sollen. Die ISS-Erzeugungskomponente erzeugt beispielhalber jeden möglichen Anfangssuchzustand für diesen Eingabesatz.
Selbstredend können Anfangssuchzustände auch in Gruppen erzeugt werden. So können Anfangssuchzustände beispielsweise lediglich für diejenigen Muster erzeugt werden, die sich zunächst aus der Anwendung der semantischen Abbildungsregeln auf die Boxenstrukturen der UDRS ergeben. Anschließend können diejenigen Muster, die durch die Blurb-Verarbeitung erzeugt werden, zu dem Prozess der Erzeugung der Anfangssuchzustände hinzugefügt werden. Auf ähnliche Weise können Anfangssuchzustände nur für Muster erzeugt werden, darunter für diejenigen, die unter Verwendung der Unempfindlichkeitsstrategien erzeugt worden sind, und zwar ausschöpfend oder bis zum Erreichen irgendeiner anderen Randbedingung, so beispielsweise einer Zeitgrenze. Alternativ können sämtliche Suchzustände unmittelbar erzeugt werden.
In jedem Fall werden die Anfangssuchzustände, die erzeugt worden sind, zusammen mit dem Schema von dem SIC 210 für den IA 214 bereitgestellt. Dies ist in dem Block 350 angegeben. Der IA 214 erzeugt Lösungsmuster durch Assemblieren beziehungsweise Zusammenfügen oder Kombinieren der Muster in den Anfangssuchzuständen entsprechend der lokalen Präferenzen, die ebenfalls dem IA 214 als Teil der Anfangssuchzustände zur Verfügung gestellt werden. Die Lösungsmuster stellen eine global äußerst bequeme Gesamtinterpretation auf Basis des Schemas und der lokalen Präferenzen dar. Die Erzeugung der Lösungsmuster ist in dem Block 352 angegeben.
Der IA 214 erzeugt die Lösungsmuster unter Verwendung der Lösungsmustererzeugungskomponente 228. Die Lösungsmuster werden wiederum dem SIC 210 zur Verfügung gestellt, der selbige Lösungsmuster, wie in Block 354 angegeben ist, empfängt, und die Boxenstruktur und die logische Struktur für die Lösungsmuster wiederherstellt. Dies erzeugt vollständig interpretierte SemDRS'en und ist in Block 356 von 4 angegeben. Die Boxen und die logische Struktur werden gegebenenfalls unter Verwendung der gespeicherten Strukturinformation sowie Erbinformation in dem Lösungsmuster wie auch durch andere in dem SIC 210 vorgehaltene Datenstrukturen wiederhergestellt.
7 ist ein Flussdiagramm, das den Initialisierungsblock 320 detailliert darstellt. Wie anhand von 5 erörtert worden ist, ist jede Eingabe-DRS beispielhalber als dynamische Anordnung logischer Elemente implementiert. Die logischen Elemente werden durch die Boxen dargestellt, wobei jede Box einen Index in die Anordnung darstellt. Während der Initialisierung zeichnet damit der Datenspeicher 215 zunächst die Boxenstruktur für die Eingabe-UDRS'en, wie in 7 in Block 400 angegeben ist, auf. Dies ist die UDRS-Datenstruktur.
Anschließend zeichnet der Datenspeicher 215 eine Liste von Tokens entsprechend der Eingabefolge 206 auf. Dies wird in Block 402 in 7 dargestellt. Eine Tokenliste für die Eingabefolge von Beispiel 1 „Lösche alle E-Mails, die nicht von KD stammen" (Delete all emails not from KD) lautet wie folgt:
Der Datenspeicher 215 initialisiert anschließend die Datenstruktur, die verwendet wird, um die durch den IFG erzeugten Ergebnisse der semantischen Abbildung zu speichern, wie in 7 in Block 404 angegeben ist. Hierbei wird leer begonnen, wobei jedoch gegebenenfalls eine Bevölkerung mit Mustern durch die Ergebnisse der Verarbeitung in dem IFG 212 erfolgt.
Von Nutzen ist eine etwas detailliertere Darstellung dahingehend, was beispielhalber ein derartiges Muster sein kann. Eine Entitätsvariable, die ein Element irgendeines Musters P ist, wird mit T(X) bezeichnet, wobei T der Name des Entitätstyps und X ein Symbol ist, das in P eindeutig ist. Auf ähnliche Weise wird eine Relation, die ein Element eines Musters P ist, mit T(X, S, D) bezeichnet, wobei T der Relationstyp, X ein Symbol, das in P eindeutig ist, S das Symbol für die Quellenentität und D das Symbol für die Zielentität ist. Ein Muster kann aus einer einzelnen Entitätsvariable, so beispielsweise [Emails(X)] be stehen. Ein Muster kann zudem durch zwei oder mehr Entitätsvariablen, die durch Relationen getrennt sind, dargestellt werden, so beispielsweise auf die nachfolgende Weise.
Emailltem(x), HasSender(Y, X, Z), Person(Z)
Die Initialisierung der PatternList-Struktur ist in Block 404 angegeben.
Der Datenspeicher initialisiert anschließend die Datenstruktur, die die Abbildung zwischen den DRS-Elementen in der Eingabe-UDRS und den Tokens in der Eingabefolge 206 ist, was von Unterkomponenten (beispielsweise Block 418 in 8) in dem IFG 212 verwendet wird, um die Token-Abdeckung der angewandten semantischen Abbildungsregeln zu bestimmen. Dies ist in Block 406 angegeben. Man beachte, dass einige Tokens nicht einem Boxenelement entsprechen, sondern vielmehr durch die Boxenstruktur dargestellt werden.
In Beispiel 1 weist die Anfangsabbildung von DRS-Elementen auf Tokens (drselems2t) das nachfolgende Aussehen auf.

KD(y) deckt Token 6 ab

email(x) deckt Token 3 ab

from(x, y) deckt Token 5 ab

delete(e, x) deckt Token 1 ab
Man beachte, dass die Tokens 4 und 2 keinem der Boxenelemente entsprechen. Ihr semantischer Beitrag geht jedoch nicht verloren, da er in der Boxenstruktur aufgezeichnet ist.
Sobald die Initialisierung vollständig ist, werden die Daten durch den IFG 212 zugänglich gemacht, und die Schemamaschine 222 in dem IFG 212 wendet sämtliche anwendbaren semantischen Abbildungsregeln auf die UDRS an. Dieser Prozess wird detaillierter in dem Flussdiagramm von 8 dargestellt.
In Beispiel 1 wird davon ausgegangen, dass der nachfolgende Satz semantischer Abbildungsregeln bereitgestellt ist.

email(x) → Emailltem(x)

from(x, y) → HasSender(x, y)

from(x, y) → HasSentTime(x, y)

delete(e, x) → DeleteAct(e) HasTarget(e, x)
Bei der Anwendung dieser Regel wählt die semantische UDRS-Abbildungsverarbeitungsmaschine 222 zunächst eine semantische Abbildungsregel, wie in 8 in Block 410 angegeben ist, aus. Die semantische Abbildungsverarbeitungsmaschine 222 vergleicht anschließend die linke Seite der semantischen Abbildungsregel mit allen Teilsätzen von Boxen in der aufgezeichneten Eingabe-UDRS-Boxenstruktur. Die semantische UDRS-Abbildungsverarbeitungsmaschine 222 bestimmt, ob die linke Seite der semantischen Abbildungsregel auf einen Teilsatz der Boxen in der Boxenstruktur, wie in Block 412 angegeben ist, passt.
Ist dies nicht der Fall, so geht die semantische UDRS-Abbildungsverarbeitungsmaschine 222 einfach zu der nächsten semantischen Abbildungsregel über und setzt die Verarbeitung fort, bis keine semantischen Abbildungsregeln, die zu prüfen wären, mehr übrig sind. Dies ist in Blöcken 414 und 416 angegeben.
Passt gleichwohl, siehe Block 412, die linke Seite einer semantischen Abbildungsregel auf einen Teilsatz der Boxenstruktur der Eingabe-UDRS, so wird die Token-Abdeckung dieser Abbildung als Vereinheitlichung beziehungsweise Union der Token-Abdeckung der UDRS-Boxenelemente bestimmt; die auf die linke Seite der ausgewählten Regel passen, und es wird die Boxennummer derjenigen, die sämtliche passenden UDRS-Boxenelemente enthält, bestimmt. Dies ist in Block 418 angegeben. Anschließend wird das SemDRS-Fragment auf der rechten Seite der ausgewählten semantischen Abbildungsregel zusammen mit der Token-Abdeckung, der Boxennummer und einer Bewertung beziehungsweise den Kosten, die mit dem SemDRS-Fragment verknüpft sind, an den IFS 215 gesendet. Dies ist in Block 420 angegeben. Die Kosten können unter Verwendung eines beliebigen bekannten Verfahrens berechnet werden, so beispielsweise durch Stützen der Kosten auf die Anzahl von Worten bei dem Treffer und die Wahrscheinlichkeit des Auftretens von Objekten in dem SemDRS-Fragment, wobei die Kosten jedoch auch einfach einen festen Wert für sämtliche semantischen Abbildungsregeln (beispielsweise 1,0) aufweisen können.
Die semantische UDRS-Abbildungsverarbeitungsmaschine 222 nimmt anschließend eine Auflockerung (loosening) vor und erhält Präferenzen, wie in Block 420 angegeben ist. Um die Auflockerung anzuwenden, werden explizite Verbindungen mit anderen Mustern in der Liste von Mustern (PatternList) durch abstrakte Entitäten ersetzt, und es werden Präferenzen erzeugt. Die Auflockerung wird detailliert nachstehend unter Bezugnahme auf 9 beschrieben.
Nach Anwendung der Auflockerung wird eine Abbildung zwischen den Mustern und den DRS-Elementen (die pat2drselems-Datenstruktur) aktualisiert. Um dies vorzunehmen, fügt die semantische UDRS-Abbildungsverarbeitungsmaschine 222 ein Paar in der pat2drselems-Abbildung, das sich auf das Muster bezieht, das der PatternList gerade hinzugeführt worden ist, der Box in der Eingabe-UDRS-Boxenstruktur hinzu, die die Erzeugung des Musters bewirkt hat. Mit anderen Worten, es wird eine Abbildung zwischen der Box, die auf die linke Seite der Abbildungsregel passt, und dem Muster in Pattern-List, das durch diesen Treffer erzeugt worden ist (das heißt, der rechten Seite der Abbildungsregel) erzeugt. Dies ist in Block 422 angegeben.
Eine Abbildung von Mustern auf Tokens, nämlich pat2t, auf Basis der Token-Abdeckung der SemDRS-Fragmente, die die Muster lizenziert haben, wird anschließend, wie in Block 424 angegeben ist, aktualisiert. Die Schemamaschine 222 greift auf die drselem2t-Abbildung zu und fügt ein Paar in der pat2t-Abbildung hinzu, das das Ausgabemuster auf die Position in der Eingabefolge bezieht. Nachdem dies beendet ist, nimmt die Schemamaschine 222 erneut eine Prüfung vor, um festzustellen, ob zusätzliche semantische Abbildungsregeln, wie in Block 414 angegeben ist, verarbeitet werden müssen.
Nach Anwendung sämtlicher Abbildungsregeln in Beispiel 1 weisen die Datenstrukturen in dem SIC 210 das nach folgende Aussehen auf:
Die UDRS-Boxenstruktur ist unverändert.
Die TokenList-Struktur ist unverändert.
Die PatternList-Struktur enthält die nachfolgenden Muster. Hierbei werden die Entitäten und Relationen in jedem Muster mit der Box in der Boxenstruktur etikettiert, in der eventuell eine Rekonstruktion erfolgt. Die pat2t-Abbildung wird ebenfalls hier spezifiziert.

P₁ Emailltem[3] deckt Token 3 ab

P₂ E₂[3] HasSender[5] E₁[1] deckt Token 5 ab

P₃ DeleteAct[4] HasTarget[4] E₃[3] deckt Token 1 ab

P₇ E4[3] HasSentTime[5] E₅[1] deckt Token 5 ab
Die Entitäten E₁, ..., E_n in den Mustern P₁, ..., P_n sind Entitäten, die als Ergebnis des Auflockerungsprozesses eingeführt worden sind. Dieser Prozess wird nachstehend detaillierter im Zusammenhang mit 9 beschrieben.
Zunächst wird ein relationales Muster aus der Musterlistendatenstruktur ausgewählt. Dies wird in 9 in Block 480 angegeben. Die Quellen- und Zielentitäten in dem ausgewählten relationalen Muster werden anschließend durch abstrakte Entitäten (so beispielsweise durch die durch E₁–E_n dargestellten) ersetzt. Dies ist in Block 482 angegeben.
Anschließend werden Präferenzen dahingehend, wie sich Muster mit abstrakten Entitäten auf andere Muster in der PatternList-Datenstruktur beziehen, erzeugt. Dies ist in Block 484 angegeben.
Aus Beispiel 1 ist ersichtlich, dass die Beziehung zwischen den Entitäten x und y in der Eingabe-DRS bei der Interpretation der Relation from(x, y) und dem übrigen Auftreten von x und y in der DRS aufgelockert worden ist. Hierdurch wird deutlich, dass die Beziehung zwischen beispielsweise der Entität entsprechend KD(y) in der Eingabe-UDRS und der Bezeichnung der HasSender-Relation in dem Schema nicht direkt sein muss. Wie das in 6 gezeigte Schema 300 abermals deutlich macht, ist dies eine wünschenswerte Auflockerung. So ist beispielsweise wahrscheinlich, dass KD(y)(durch die vorstehend beschriebene Blurb-Komponente) als eine Folge interpretiert wird, und HasSender Emailltems mit Entitäten des Typs Person verbindet. Durch Auflockerung dieser Beziehung kann die IA-Komponente 214 diese Interpretation der Folge von KD(y) auf das Ziel HasSender beziehen, indem eine Entität Person eingeführt wird, und indem die Folge auf jede Entität über die HasName-Relation bezogen wird.
Es wurde ebenfalls deutlich, dass die Beziehung zwischen der Entität e in der Eingabe-UDRS und der Quelle der HasTarget-Relation nicht aufgelockert worden ist. Dies unterscheidet sich vom vorhergehenden Fall darin, dass die Verbindung zwischen E und der HasTarget-Relation in einer einzigen semantischen Abbildungsregel explizit gemacht worden war. Man geht daher davon aus, dass die rechte Seite der semantischen Abbildungsregeln logische Verbindungen in dem Schema darstellt, wodurch die Notwendigkeit für eine Auflockerung beseitigt wird.

In Beispiel 1 treten beim Anwenden der semantischen Abbildungsregeln und des Auflockerungsprozesses (der in 8 in Block 420 angegeben ist) die nachfolgenden Präferenzen (das Muster P4 wird bezüglich der nachstehenden Blurb-Verarbeitung diskutiert) auf.

H₁:	Emailltem von P₁ nahe an E₂ von P₂
H₂:	E₁ von P₂ nahe an Blurb („KD") von P₄
H₃:	E₃ von P₃ nahe an Emailltem von P₁
H₄:	E₄ von P₇ nahe an Emailltem von P₁
H₅:	E₅ von P₇ nahe an Blurb („KD") von P₄

Nachdem die Abbildung zwischen den vorgenannten Mustern und den diese lizenzierenden DRS-Elementen spezifiziert ist (das heißt, nachdem die pat2drselems-Datenstruktur, wie in Block 422 in 8 dargestellt, aktualisiert worden ist), sieht die Abbildung folgendermaßen aus.

P₁:	Emailltem[3] wird abgebildet auf email(x)
P₂:	E₂[3] HasSender[5] E₁[1] wird abgebildet auf from(x, y)
P3:	DeleteAct[4] HasTarget[4] E₃[3] wird abgebildet auf delete(e, y)
P₇:	E₄[3] HasSentTime[5] E₅[1] wird abgebildet auf from(x, y)

Diese Abbildung formalisiert tatsächlich das Kürzel [] in den Mustern. Es ist beispielsweise ersichtlich, dass email(x) in Box 3 der ursprünglichen UDRS-Struktur aufgetreten ist. Daher ist bekannt, dass die UDRS entsprechend Muster P₁ in jener Box rekonstruiert werden sollte.
An diesem Punkt ist die Tätigkeit der Schemamaschine 222 in dem IFG 212 beendet. Man beachte, dass für den Fall, dass eine Packung der Ergebnisse an diesem Punkt in teilweise interpretierte SemDRS'en gewählt worden ist, genug Information vorhanden ist. So ergeben sich beispielsweise zwei SemDRS'en, nämlich eine, in der „from" als Has-Sender interpretiert wird, und eine, in der dieses Element als HasSentTime interpretiert wird.
Jede in der semantischen Schicht erzeugte SemDRS ist Gegenstand einer Vielzahl von Randbedingungen beziehungsweise Beschränkungen bezüglich der Wohlgeformtheit, durch die sichergestellt wird, dass Interpretationen, deren Verwendung aussichtslos ist, nicht erzeugt werden. Zu diesen Randbedingungen zählen beispielsweise Inkonsistenzen vom ruling-out-Typ (ruling out type inconsistencies) und ungünstige Interpretationen, die nicht zu dem bestimmten Schema, das gerade verwendet wird, passen. Derartige Bedingungen betreffend die Geformtheit ermöglichen das Ausscheiden unplausibler Interpretationen in jeder Phase des Interpretationsprozesses.
10 ist ein detaillierteres Blockdiagramm der Blurb-Verarbeitung entsprechend einem Ausführungsbeispiel der vorliegenden Erfindung. Die Blurb-Verarbeitung übernimmt das, was in der UDRS noch zu interpretieren ist, und interpretiert dies derart als Blurb, dass ein Interpretationsfragment (und daher ein Muster) für jene Information erzeugt werden kann. Zusätzlich werden alternative Interpretationen für bestimmtes Material, das Anlass zu SemDRS-Fragmenten gegeben hat, angeboten. So kann man beispielsweise die Erzeugung einer Blurb-Interpretation für eine Äußerung als Ganzes wählen, wenn Anlass zu der Vermutung besteht, dass hierfür eine Interpretationsfolge, die für eine Suchmaschine geeignet ist, vorhanden ist.
Bei dem vorliegenden Beispiel ist KD(y) das einzige Boxenelement, das noch nicht interpretiert worden ist, wobei KD(y) Token 6 in der Eingabefolge entspricht. Um die Blurb-Verarbeitung an dieser Information auszuführen, identifiziert die UDRS-Blurb-Verarbeitungsmaschine zunächst das nichtinterpretierte Material in der Eingabe-UDRS. Dies ist in 10 in Block 490 angegeben. Das identifizierte Material wird anschließend als Blurb-Muster mit damit verknüpften Kosten interpretiert. Dies ist in Block 492 angegeben. Die Kosten können beliebige gewünschte Kosten sein. So können die Kosten eines Musters, das durch eine Blurb-Verarbeitung erzeugt worden ist, beispielsweise 2,0 + 1,75 pro Wort betragen. Selbstredend kann eine beliebige andere Größe zur Messung der Kosten eingesetzt werden.
Sobald das Muster erzeugt worden ist, wird die pat2t-Abbildungsdatenstruktur, wie in Block 494 angegeben ist, aktualisiert. Die Auflockerung wird anschließend angewandt, und man erhält Präferenzen, wie in Block 496 angegeben ist. Die pat2drselems-Abbildungsstruktur wird ebenfalls, wie in Block 498 angegeben ist, aktualisiert.

Nachdem diese Aktualisierungen ausgeführt worden sind, haben die PatternList- und die pat2t-Abbildungsstrukturen das nachfolgende Aussehen.

P₁:	Emailltem[3] deckt Token 3 ab
P₂:	E₂[3] HasSender[5] E₁[1] deckt Token 5 ab
P₃:	DeleteAct[4] HasTarget[4] E₃[3] deckt Token 1 ab
P₄:	Blurb („KD")[0] deckt Token 6 ab
P₇:	E₄[3] HasSentTime[5] E₅[1] deckt Token 5 ab

Der Satz von Präferenzen sieht folgendermaßen aus.

Schließlich wird das nachfolgende Paar zu der pat2drselems-Abbildungsdatenstruktur hinzugefügt.

P₁: Blurb(„KD") wird abgebildet auf KD(y)
An diesem Punkt können die Anfangssuchzustände erzeugt werden: Entsprechend einem als Beispiel angegebenen Ausführungsbeispiel werden die Unempfindlichkeitsstrategien vor der Erzeugung der Anfangssuchzustände implementiert. Diese Strategien können gleichwohl sowohl vor wie auch nach Erzeugung eines Anfangssatzes von Anfangssuchzuständen implementiert werden, was nachstehend aus Gründen der Vollständigkeit beschrieben wird.
11 ist ein Flussdiagramm, das die Implementierung von Unempfindlichkeitsstrategien eingehend darstellt. Die Unempfindlichkeitsstrategien werden implementiert, um unkorrekte oder angepasste Analysen eines gegebenen Satzes auszugleichen oder Eingaben zu verarbeiten, für die keine geeignete syntaktische Analyse vorhanden ist. Ist die Anwendung beispielsweise eine Informationsbeschaffungssuchmaschine, so können Anwender unvollständige Sätze als Suchabfragen verwenden. In diesem Fall können bestimmte Teile in der Eingabefolge vollständig in der UDRS-Struktur ignoriert werden.
Daher zählt die Unempfindlichkeitsstrategienverarbeitungsmaschine 226 das gesamte durch die Analyse erhaltene linguistische Belegmaterial ohne in der UDRS reflektierte strukturelle Randbedingungen auf.
Diese Unempfindlichkeitsstrategien können beispielsweise angewandt werden, um Muster entsprechend dem linguistischen Belegmaterial, das durch den Prozess der Erstellung von Anfangssuchzuständen aus der Eingabe-UDRS nicht abgedeckt worden ist, hinzuzufügen, und anschließend zusätzliche Suchzustände für jene Muster als alternative Möglichkeiten der Erstellung von Lösungen in dem IA 214 zu erzeugen. Während der Implementierung der Unempfindlichkeitsstrategien erzeugte Muster werden beispielhalber niedriger als diejenigen, die durch die Anwendung semantischer Abbildungsregeln auf die UDRS-Struktur erzeugt worden sind, wie auch als diejenigen, die durch die Blurb-Verarbeitung erzeugt worden sind, eingeordnet. Daher können die Suchzustände, die aus diesen Mustern erzeugt worden sind, beispielhalber von dem IA 214 nur dann beigezogen werden, wenn ein Versagen bei der Erzeugung passender Lösungen entsprechend dem durch die Eingabe-UDRS und die Blurbs lizenzierten Muster vorliegt.
Zum besseren Verständnis der Implementierung der Unempfindlichkeitsstrategien wird ein weiteres Beispiel (Beispiel 2) angegeben. Man betrachte die nachfolgende Eingabefolge und Tokenliste.
Die Eingabe-UDRS ist in 11–1 angegeben.
Unter Verwendung desselben Schemas wie in 6 wird ein Satz semantischer Abbildungsregeln im Zusammenhang mit dieser Eingabe-UDRS folgendermaßen hergeleitet.

email(x) → Emailltem(x)

email(u, w) → InitEmailAct(u), HasTarget(u, w)

you(y) → (muss entfernt werden)

about(e, z) → HasSubject(e', z')
sNachdem die semantischen Abbildungsregeln auf die Eingabe-UDRS von dem IFG 212 angewendet worden sind, und nachdem Blurbs, wie durch die UDRS-Strukturen nahegelegt, erzeugt worden sind, ergeben sich die nachfolgenden Muster.

P₁: Emailltem[1] deckt Token 1 ab

P2: E₁[1] NasSubject[1] E₂[1] deckt Token 4 ab

P₃: Blurb(„Majel")[1] deckt Token 5 ab

P₄: vernachlässigbar deckt Token 2 ab
Die nachfolgende Präferenz wurde ebenfalls ermittelt.

H₁: E₂ von P₂ nahe an Blurb („Majel") von P₃
Es ist ersichtlich, dass die semantische Abbildungsregel für den verbalen Sinn „email" nicht für die Eingabe-UDRS gilt, was durch die Tatsache bedingt ist, dass die Analyse nicht korrekt war. Das heißt, es wurde ein Nomen in der Eingabe-UDRS anstelle eines Verbs analysiert. Es ist zudem ersichtlich, dass das Wort „Harry" in dem Eingabesatz als Verb auf Basis der Boxenstruktur erkannt wird und als Relation in der Eingabe-UDRS dargestellt wird. Es gibt keine anwendbaren semantischen Abbildungsregeln. Darüber hinaus sind ungeachtet der Tatsache, dass die UDRS-Struktur Blurb-Interpretationen für das Material nahelegen kann, derartige Interpretationsfragmente für die beabsichtigte endgültige Interpretation nicht geeignet. Der Effekt hiervon besteht darin, dass das Material nicht zu einer beliebigen gewünschten endgültigen SemDRS beiträgt.
Die vorliegenden Unempfindlichkeitsstrategien können jedoch zum Auffinden einer vergleichsweise guten Lösung beitragen. Um diese Strategie zu implementieren, wird zunächst ein ignoriertes beziehungsweise vernachlässigtes Token, wie in 11 in Block 500 angegeben ist, ausgewählt. Die Maschine 226 wendet anschließend einfachere folgenbasierte Umschreibregeln auf das ausgewählte Token an, um zusätzliche Muster und die damit verknüpften Kosten zu erzeugen. Diese Umschreibregeln können von dem Entwickler verfasst oder aus dem Schema hergeleitet werden. Dies ist in Block 502 angegeben. Die sich ergebenden Muster sind beispielhalber mit höheren Anfangskosten als diejenigen verknüpft, die durch Anwenden der semantischen Abbildungsregeln auf die Eingabe-UDRS erzeugt worden sind.
Die in diesen Mustern erzeugten Entitäten und Relationen werden etikettiert, wodurch sich ergibt, dass sie nicht zu einer Box in der Eingabe-UDRS gehören. Dies ist in Block 504 angegeben. Bei dem vorliegenden Beispiel werden die nachfolgenden Muster hinzugefügt.

P₅: InitEmailAct[0] deckt Token 1 ab

P₆: E₃[0] HasEmailAddr[0] E₄[O] deckt Token 1 ab

P₇: E₅[0] HasRecipient[0] E₆[0] deckt Token 2 ab

P₈: E₇[0] HasTarget[0] E₈[0] deckt Token 2 ab
Die Maschine 222 bestimmt anschließend, ob die zusätzlichen Tokens einer Verarbeitung bedürfen. Dies ist in Block 506 angegeben. Ist dem so, so kehrt die Verarbeitung zu Block 500 zurück. Ist dem hingegen nicht so, so bestimmt die Maschine 226, ob namenartige Entitäten ignoriert worden sind. Dies ist in Block 508 angegeben. Es existieren im Wesentlichen zwei Fälle, in denen eine namenartige Entität in der Eingabe-UDRS ignoriert werden kann. Erstens: für den Fall, dass die namenartige Entität mit der Analyse verträglich ist, jedoch eine andere namenartige Entität (desselben Wortbereiches) durch die Analyse ausgewählt worden ist, wird die erste namenartige Entität ignoriert. Zweitens: für den Fall, dass die namenartige Entität überhaupt nicht mit der Analyse verträglich ist, wird sie ignoriert.
In beiden Fällen gilt: Wird die namenartige Entität ignoriert, so werden Muster mit ignorierten namenartigen Entitäten mit vergleichsweise niedrigem Rang erzeugt. Dies ist in Block 510 angegeben. Das vorliegende Beispiel umfasst keine derartigen namenartigen Entitäten.
Zudem gilt, dass bestimmte Blurbs die Eingabe-UDRS-Struktur (einschließlich Blurbs, die Worte geeignet abdecken, die in der Eingabe-UDRS-Struktur ignoriert worden sind) verletzten. Blurb-Muster werden für derartige Blurbs auf Basis des Syntaxanalysebaumes oder der logischen Form oder einer Heuristik erzeugt, die einen niedrigeren Rang als die Blurbs innehaben, die durch die UDRS-Struktur erzeugt worden sind. Dies ist in Block 512 angegeben. Derartige Blurbs lauten in Beispiel 2 folgendermaßen.

P₉: Blurb(„Harry")[0]deckt Token 2 ab

P₁₀: Blurb(„an Harry")[0] deckt Token 2, 3 ab

Auf Basis des Syntaxanalysebaumes oder der logischen Form können auch zusätzliche Präferenzen erzeugt werden. Derartige Präferenzen basieren auf dem Ort durch diese Muster abgedeckter Worte relativ zueinander in dem ursprünglichen Eingabesatz. Die Erzeugung derartiger Präferenzen ist in Block 514 angegeben, wobei derartige Präferenzen im vorliegenden Beispiel folgendermaßen lauten.

H₂:	InitEmailAct von P₅ nahe an E₅ oder E₆ von P₇
H₃:	InitEmailAct von P₅ nahe an E₇ oder E₈ von P₈
H₄:	E₅ oder E₆ von P₇ nahe an Blurb („Harry") von P₉
H₅:	E₅ oder E₈ von P₈ nahe an Blurb („Harry") von P₉

Die Anfangssuchzustände können anschließend unter Verwendung dieser Muster erzeugt werden.
12 ist ein Flussdiagramm, das die Erzeugung der Anfangssuchzustände durch die ISS-Erzeugungskomponente 218 in dem SIC 210 darstellt. Die Erzeugung der Anfangssuchzustände wird nachstehend unter Bezugnahme auf das vorstehend genannte Beispiel 1 beschrieben. Man beachte, dass die Anfangssuchzustände vor der Implementierung der Unempfindlichkeitsstrategien erzeugt werden können, und dass die Unempfindlichkeitsstrategien auch nur im Bedarfsfalle implementiert werden können. Alternativ können die Anfangssuchzustände auch nach der Implementierung der Unempfindlichkeitsstrategien implementiert werden. In jedem Fall enthalten die Anfangssuchzustände drei Arten von Information: (1) einen Satz von Mustern, der die Eingabefolge abdeckt; (2) eine Abbildung von Mustern auf Tokens in der Eingabefolge (die pat2t-Datenstruktur); und (3) einen Satz von Präferenzen, der mit den Mustern in Beziehung steht.
Sogar vor der Implementierung der Unempfindlichkeitsstrategien ist diese Information verfügbar, mit der möglichen Ausnahme einer Abbildung von einem beliebigen Muster auf Worte, die nicht entweder durch eine semantische Abbildungsregel oder einen Blurb (so beispielsweise Worte, deren semantischer Inhalt in der Blockstruktur wiedergegeben wird, wie „nicht" und „alle" in vorstehendem Beispiel) interpretiert worden sind. Wenn also die Suchzustände vor den Unempfindlichkeitsstrategien erzeugt worden sind, so wird der Suchzustand damit durch die zunächst erfolgende Identifizierung dieser Tokens, wie in Block 520 angegeben ist, und durch Hinzufügen ignorierbarer beziehungsweise vernachlässigbarer Muster zu der PatternList-Datenstruktur zur Abdeckung der identifi zierten Tokens, wie in Block 522 angegeben ist, vervollständigt. In Beispiel 1 würde dies das Hinzufügen der nachfolgenden beiden Muster zu der PatternList betreffen.

P₅: vernachlässigbar deckt Token 2 ab

P₆: vernachlässigbar deckt Token 4 ab
Anschließend werden mögliche Anfangssuchzustände aus der Musterliste sowie Abbildungen derart gebildet, dass sämtliche Teile der Eingabe-UDRS irgendeinem Muster entsprechen, und kein Teil durch mehr als ein Muster abgedeckt ist. Dies ist in Block 524 angegeben.
Werden die Anfangssuchzustände vor der Implementierung der Unempfindlichkeitsstrategien erzeugt, so werden sämtliche möglichen Anfangssuchzustände auf Basis der Muster der PatternList-Datenstruktur und der Abbildungen gebildet. Sind demgegenüber die Unempfindlichkeitsstrategien bereits implementiert worden, und die Anfangssuchzustände werden ebenfalls für jene Muster erzeugt, so kann die Anzahl der Anfangssuchzustände, die möglicherweise erzeugt werden kann, exponentiell sein. Daher kann die Erzeugung von Anfangssuchzuständen auf Basis von Mustern, die bei den Unempfindlichkeitsstrategien erzeugt werden, auf einige wenige Kriterien, so beispielsweise die Zeit, eingeschränkt werden.
Sobald eine ISS-Erzeugungseinschränkung beziehungsweise Randbedingung vorgefunden worden ist (beispielsweise sobald alle möglichen Suchzustände auf Basis eines Musters, das von der Eingabe-UDRS und Blurbs erzeugt worden ist, erzeugt worden sind, und sobald die maximale Zeit für die Anfangssuchzustände, die auf Basis von Mustern durch die Unempfindlichkeitsstrategien erzeugt worden sind, erreicht ist), ist die Erzeugung der Anfangssuchzustände beendet, woraufhin jene Suchzustände dem IA 214 zur Verfügung gestellt werden. Dies ist durch die Blöcke 526 und 528 angegeben. Erneut wurden Anfangssuchzustände auf Basis derjenigen Muster, die durch die Unempfindlichkeitsstrategien erzeugt worden sind, durch Belegmaterial außerhalb der Eingabe-UDRS lizenziert. Daher werden diese im Allgemeinen niedriger als die anderen Anfangssuchzustände eingeordnet.
13 ist ein Flussdiagramm, das den gesamten Betrieb der Lösungsmustererzeugungskomponente 228 in dem IA 214 näher darstellt. Die Lösungsmustererzeugungskomponente 228 empfängt zunächst das Schema und die Anfangssuchzustände von dem SIC 210. Dies ist in Blöcken 600 und 602 in 13 angegeben. Die Anfangssuchzustände sind wiederum SemDRS-Fragmente, die mit Kosten verknüpft sind, zusammen mit Präferenzen, die die Kosten der spezifischen Kombinationen der SemDRS-Fragmente senken können, zusammen mit einer Abbildung von den Mustern auf die Tokens in der Eingabefolge (das heißt pat2t).
Der Lösungsmustergenerator 228 nimmt anschließend eine heuristische Suche der Anfangssuchzustände vor, um Lösungsmuster zu ermitteln. Es handelt sich hierbei um ein Optimierungsproblem, bei dem der Generator 228 versucht, die Muster zu einem Lösungsmuster zusammenzufügen, und zwar entsprechend den bereitgestellten Präferenzen und zu niedrigsten Kosten. Die Suche ist in 13 in Block 604 angegeben.
Das Ergebnis der Suche erzeugt eine Folge von Lösungsmustern, die nach ansteigenden Kosten angeordnet sind. Die Kosten sind eine Funktion der Wahl der Fragmente, der gegenseitigen Nähe (Proximität) der Fragmente in dem Schema wie auch der Erfüllung der bereitgestellten Präferenzen. Die Erzeugung der Lösungsmuster ist in Block 606 angegeben.
Der IA 214 ruft anschließend den DRS-Strukturwiederherstellungsgenerator 220 in dem SIC 210 auf. Der Generator 220 stellt die Boxenstruktur für die Lösungsmuster wieder her, um vollständig interpretierte SemDRS'en zu erzeugen. Dies ist in Block 608 angegeben.
Die Boxenstruktur für die Lösungsmuster wird durch Zugriff auf die Abbildung der in den Lösungsmustern verwendeten Muster zu der Eingabe-UDRS-Boxenstruktur wiederhergestellt. Jene Muster werden gegebenenfalls in derselben Boxenstruktur wie die in der Eingabe-UDRS vorgefundenen angeordnet.
1 ist ein Flussdiagramm, das die Implementierung der Heuristik und des Lösungsmustergenerators 228 näher darstellt. Bei einem als Beispiel angegebenen Ausführungsbeispiel ist die Heuristik eine Variante des bekannten A*-Algorithmus. Kurz gesagt bedeutet dies, dass der Generator 228 zunächst einen Satz von Anfangssuchzuständen, wie in Block 610 angegeben ist, aussucht. Für jeden Anfangssuchzustand in der Menge werden die minimalen Kosten G von dem IFG 212 auf Basis der mit den Mustern in dem Anfangssuchzustand verknüpften Kosten berechnet. Dies ist in Block 612 angegeben. Anschließend werden für jeden Anfangssuchzustand in dem Satz die zu sätzlichen Kosten H für die Erzeugung einer Lösung unter Verwendung des Suchzustandes abgeschätzt. Dies ist in Block 614 angegeben. Die Suchzustände werden anschließend nach Werten ansteigender Gesamtkosten G + H sortiert. Dies ist in Block 616 angedeutet.
Sobald die Suchzustände anfänglich auf diese Weise sortiert worden sind, wird der Suchzustand mit den niedrigsten Gesamtkosten, der in diesem Schritt noch nicht verarbeitet worden ist, ausgewählt. Dies ist in Block 618 angegeben. Aus dem ausgewählten Suchzustand werden sämtliche möglichen neuen Suchzustände durch Kombinieren von Fragmenten in dem ausgewählten Suchzustand auf verschiedene Weisen erzeugt. Dies ist durch Block 620 angegeben und wird nachstehend unter Bezugnahme auf 15 näher beschrieben. Für jeden der neuen Suchzustände, die in Block 620 erzeugt worden sind, werden neue Minimalkosten G' und neue geschätzte Kosten H' berechnet. Dies ist in Block 622 angegeben. Auf Basis der Fragmentkombinationen werden Rabatte (Nachlässe), die mit jeder der anwendbaren Präferenzen verknüpft sind, wie in Block 624 angegeben ist, angewendet.
Die Präferenz bietet einen Rabatt für jede mögliche Lösung, in der bestimmte Interpretationsfragmente in einer bestimmten Anordnung (gemäß Spezifizierung durch die Präferenz) auftreten. Das Vorhandensein der Präferenz spiegelt das linguistische Belegmaterial wieder und stellt sicher, dass eine Lösung, die dem linguistischen Belegmaterial entspricht, vor einer anderen angeordnet wird. Man beachte, dass Rabatte während der Erzeugung der Lösungsmuster und nicht bei den Lösungsmustern als Ganzes angewendet werden, nachdem diese erzeugt worden sind. Zu den Beispielen für verwendbare Präferenzen zählen die nachfolgenden Präferenzen.

1. Starke Quellen-/Zielpräferenzen. Bei dieser als Beispiel angegebenen Präferenz gilt: Geben sowohl das linguistische Belegmaterial wie auch das Schema an, dass ein Fragment auf der Quellen- oder Zielseite eines weiteren Fragmentes erscheinen sollte, und ist dies auch tatsächlich der Fall, so ist diese Präferenz angewandt worden, und ein Rabatt (von beispielsweise 0,75) wird dem Lösungsmuster gewährt.
2. Schwache Quellen-/Zielpräferenzen. Gibt lediglich das linguistische Belegmaterial an, dass ein Fragment auf der Quellen- oder Zielseite des anderen Fragmentes vorkommen sollte, und ist dies tatsächlich der Fall, so trifft diese Präferenz zu, und es wird ein Rabatt (von beispielsweise 0,5) gewährt.
3. Proximitätspräferenz. Das Schema oder das linguistische Belegmaterial zeigen, dass zwei Fragmente möglichst nahe aneinander angeordnet werden sollen. Trifft dies tatsächlich zu, so ist diese Präferenz gegeben, und es wird ein Rabatt (von beispielsweise 0,25) gewährt.

Sobald die Präferenzen angewendet worden sind, bestimmt der Lösungsmustergenerator 228, ob Lösungsmuster vollendet worden sind. Ein Suchzustand wird ausgegeben, und zwar zusammen mit den damit verknüpften Kosten G' als Suchmuster, wenn sämtliche Fragmente in dem Suchzustand zu einem einzigen Fragment kombiniert oder vereinheitlicht worden sind. Dies ist in Block 626 angegeben.
Die Verarbeitung geht dann zu Block 628 über, wo der Generator 228 bestimmt, ob mehr Suchzustände vorhanden sind, die in diesem Schritt verarbeitet werden sollen. Ist dem so, so kehrt die Verarbeitung zu Block 618 zurück, und es wird der Suchzustand mit den nächstniedrigeren Gesamtkosten, der in diesem Schritt noch nicht verarbeitet worden ist, ausgewählt.
Sind in Block 628 keine weiteren Suchzustände zur Verarbeitung in diesem Schritt vorhanden, so bestimmt der Generator 628, ob noch Suchzustände übrig sind, die einer Verarbeitung bedürfen (das heißt, ob noch Suchzustände vorhanden sind, die nicht vollständig zu einem Fragment zur Bildung eines Lösungsmusters kombiniert worden sind). Dies ist in Block 630 angegeben. Sind derartige Suchzustände vorhanden, so kehrt die Verarbeitung zu Block 616 zurück, wo die verbleibenden Suchzustände nach dem Wert ansteigender Gesamtkosten G' + H' sortiert und erneut verarbeitet werden, wobei die niedrigsten Kosten zuerst verarbeitet werden. Sobald sämtliche Suchzustände vollständig verarbeitet worden sind, ist die Lösungsmustererzeugung, wie in Block 632 angegeben ist, beendet.
Man beachte, dass für lange Sätze und mehrdeutige semantische Abbildungen die Anzahl von Anfangssuchzuständen unerwünscht groß sein kann. Dies kann zu einer verboten langen Verarbeitungszeit führen, um diese Suchzustände aufzustellen, wobei dann nur vergleichsweise wenige tatsächlich untersucht werden können. Die Suchzustände können somit weiter derart beschränkt werden, dass nur diejenigen erzeugt werden, die den Interpretationen von Eingabe-UDRS-Elementen entsprechen, die eine vergleichsweise große Proximität in dem Anwendungsschema aufweisen. Aus diesen Anfangssuchzuständen erhaltene Lösungen müssen nicht notwendigerweise die preisgünstig sten Lösungen sein, die vorgefunden werden können; es ist jedoch wahrscheinlich, dass es sich dabei um die preisgünstigsten handelt. Darüber hinaus kann diese Beschränkung beispielhalber nur dann Anwendung finden, wenn die Eingabesätze unerwünscht lang sind. Daher können diese Randbedingungen beziehungsweise Beschränkungen beispielhalber nicht einmal für Sätze annehmbarer Länge implementiert sein.
15 ist ein Flussdiagramm, das allgemein darlegt, wie Muster in dem Lösungsmustergenerator 228 des IA 214 kombiniert werden. Um die Muster oder Fragmente des Anfangssuchzustandes zu kombinieren, empfängt der Lösungsmustergenerator 228 zunächst zwei Muster und die damit verknüpften Präferenzen für einen Anfangssuchzustand, zusammen mit dem Schema. Dies ist in 15 in Block 650 angegeben. Der Generator 228 bestimmt anschließend, ob Entitäten oder Relationen in den Mustern vereinheitlicht werden können. Dies ist in Block 652 angegeben. Die Muster können beispielsweise folgendermaßen aussehen.
P1 = Entität 1, Relation 1, Entität 2; und
P2 = Entität 3, Relation 2, Entität 4
Die Entitäten 2 und 3 sind vereinheitlichbar, wenn die Entitäten 2 und 3 identisch sind, oder wenn die eine ein transitiver Untertyp der anderen ist.
Ist dies der Fall, führt dies zu einem kombinierten Muster, das folgendermaßen aussieht.
Entität 1, Relation 1, vereinheitlichte Entität 2/3, Relation 2, Entität 4
Relationen sind vereinheitlichbar, wenn sie denselben Typ aufweisen, wenn ihre Quellen vereinheitlicht werden können, und wenn ihre Ziele vereinheitlicht werden können.
In jedem Fall gilt: Können die Entitäten oder Relationen in den beiden gewählten Mustern, wie in Block 652 dargestellt, vereinheitlicht werden, so werden die Muster vereinheitlicht, und die Kosten können gegebenenfalls Anwendung finden. Bei dem als Beispiel angegebenen Ausführungsbeispiel sind die Kosten für die Vereinheitlichung der Muster oder Relationen gleich 0. Dies ist in Block 654 angegeben.
Können beispielsweise, siehe Block 652, die Entitäten oder Relationen in den empfangenen Mustern nicht vereinheitlicht werden, so ermittelt der Lösungsmustergenerator 228 den am wenigsten teueren Pfad durch das Schema, der eine Entität aus jedem der Muster verbindet. Dies ist in Block 656 angegeben. Die Kosten jedes Paares in dem Schema können vorab berechnet werden. Sie können selbstredend auch zur Laufzeit berechnet werden. Sind die Kosten für zwei Pfade gleich, so wird beispielhalber der kürzeste Pfad als der am wenigsten teuere Pfad gewählt.
Sobald der am wenigsten teuere Pfad in Block 656 identifiziert worden ist, fügt der Generator 228 notwendige Relationen und Entitäten hinzu, um die beiden Muster entsprechend dem Schema zu verbinden, und wendet die damit verknüpften Kosten auf das neue verbundene Muster an. Dies ist in Block 658 angegeben.
Wie in 14 angegeben ist, werden die neukombinierten Muster anschließend bewertet und nach Bewertung sortiert, woraufhin die Kombination und Vereinheitlichung fortgesetzt wird, bis der Suchzustand durch ein einziges Fragment dargestellt ist, wobei es sich in diesem Fall um ein Lösungsmuster handelt. Aufgrund der konstanten Bewertung und Sortierung ist sichergestellt, dass der IA 214 die am höchsten angeordneten (am wenigsten teueren) Lösungsmuster zuerst auffindet.
Es ist ersichtlich, dass die vorliegende Erfindung eine DRS auf eine verwendbare normalisierte Datenstruktur als Eingabe für ein semantisches Analysesystem normalisiert.
Obwohl die vorliegende Erfindung unter Bezugnahme auf bestimmte Ausführungsbeispiele beschrieben worden ist, erschließt sich einem Fachmann auf dem einschlägigen Gebiet unmittelbar, dass Veränderungen an Form und Einzelheiten vorgenommen werden können, ohne den Schutzumfang der vorliegenden Erfindung zu verlassen.
Anhang A
Bemerkungen

• Sobald die Elemente einer Box entsprechend <_a (Schritt 3) oder <_b (Schritt 12) sortiert worden sind, kann dies in einem zusätzlichen Feld der Boxenimplementierung aufgezeichnet werden, sodass bei einem mehr als einmaligen Auftreten derselben Box der Sortieralgorithmus nochmals angewandt werden muss.
• Der vorliegende Algorithmus modifiziert die Eingabe-DRS derart, dass diese normalisiert wird. Wird der Algorithmus derart modifiziert, dass er anstatt dessen eine normalisierte Kopie der Eingabe-DRS ausgibt, so wird der used_boxes-Vektor beseitigt. Dessen einziger Zweck besteht darin, die Boxen, wenn sie kopiert werden, zu speichern, um zu vermeiden, dass eine Box überschrieben wird, bevor sie kopiert worden ist. Die Reihenfolge, in der Boxenelemente kopiert werden, stellt sicher, dass jedes Boxenelement, das überschrieben wird, entweder bereits kopiert worden ist oder aussortiert werden sollte.

Claims

Computerimplementiertes Verfahren zum Normalisieren einer Diskursrepräsentationsstruktur (250), die Boxen mit Boxenelementen und Boxenelement-Argumenten mit Markierungen, Boxen-Kennungen und Datenwerten enthält, wobei das Verfahren durch ein Textverarbeitungs-Computersystem (200) durchgeführt wird und das Verfahren dadurch gekennzeichnet ist, dass es umfasst: Erzeugen einer Boxen- und Boxenelement-Normalform durch Normalisieren der Form, in der Boxen und Boxenelemente in der Diskursrepräsentationsstruktur dargestellt werden, wobei das Normalisieren Identifizieren und Löschen (253) ungenutzter Boxen und ungenutzter Boxenelemente aus der Diskursrepräsentationsstruktur umfasst; Sortieren (257) der Boxen und Boxenelemente auf Basis der Boxen- und Boxenelement-Normalform und unabhängig von den Markierungen, um eine vorläufige Ordnung herzustellen; Normalisieren einer Form, in der Markierungen in der Diskursrepräsentationsstruktur dargestellt werden; und Sortieren (265) der Boxen und Boxenelemente auf Basis der vorübergehenden Ordnung und auf Basis der Markierungs-Normalform, um eine Normalform für die Diskursrepräsentationsstruktur zu erreichen.
Computerimplementiertes Verfahren nach Anspruch 1, wobei Normalisieren der Form, in der Boxen dargestellt werden, umfasst: Umnummerieren (255) der Boxen mit aufeinander folgenden Indizes.
Computerimplementiertes Verfahren nach Anspruch 2, wobei Normalisieren der Form, in der Boxenelemente dargestellt werden, umfasst: Umnummerieren der Boxenelemente mit aufeinander folgenden Kennungen.
Computerimplementiertes Verfahren nach Anspruch 3, wobei Sortieren der Boxen und Boxenelemente auf Basis der Boxen- und Boxenelement-Normalformen und unabhängig von den Markierungen umfasst: lexikografisches Ordnen (257) der Boxen und Boxenelemente auf Basis der Indizes und Kennungen, um lexikografisch geordnete Boxen und Boxenelemente herzustellen.
Computerimplementiertes Verfahren nach Anspruch 4, wobei Sortieren der Boxen und Boxenelemente auf Basis der Boxen- und Boxenelement-Normalformen und unabhängig von den Markierungen umfasst: Aktualisieren der Boxen, so dass sie sich auf umnummerierte Boxenelemente beziehen.
Computerimplementiertes Verfahren nach Anspruch 5, wobei Sortieren der Boxen und Boxenelemente auf Basis der Boxen- und Boxenelement-Normalformen und unabhängig von den Markierungen umfasst: Aktualisieren der Boxenelemente, so dass sie sich auf umnummerierte Boxen beziehen.
Computerimplementiertes Verfahren nach Anspruch 6, wobei Normalisieren der Form, in der Markierungen in der Diskursrepräsentationsstruktur dargestellt werden, umfasst: Erzeugen einer Abbildung (261) zwischen jeder Markierung und einer Liste, die eine Box und ein Boxenelement identifiziert, das die Markierung enthält.
Computerimplementiertes Verfahren nach Anspruch 7, wobei Normalisieren der Form, in der Markierungen in der Diskursrepräsentationsstruktur dargestellt werden, umfasst: Erzeugen einer umgekehrten Abbildung zwischen der Liste, die eine Box und ein Boxenelement identifiziert, das eine Markierung enthält, und jeder Markierung.
Computerimplementiertes Verfahren nach Anspruch 8, wobei Normalisieren der Form, in der Markierungen in der Diskursrepräsentationsstruktur dargestellt werden, umfasst: Umnummerieren (263) der Markierungen mit aufeinander folgenden Markierungswerten.
Computerimplementiertes Verfahren nach Anspruch 9, wobei Normalisieren der Form, in der Markierungen in der Diskursrepräsentationsstruktur dargestellt werden, umfasst: Aktualisieren der Boxenelemente, so dass sie sich auf die umnummerierten Markierungen beziehen.
Computerimplementiertes Verfahren nach Anspruch 10, wobei Sortieren (265) der Boxen und Boxenelemente auf Basis der vorübergehenden Ordnung und auf Basis der Markierungs-Normalformen umfasst: Sortieren der lexikografisch geordneten Boxen und Boxenelemente auf Basis der umnummerierten Markierungen, um eine normalisierte Diskursrepräsentationsstruktur herzustellen.
Computerimplementiertes Verfahren nach Anspruch 11, das des Weiteren umfasst: Erzeugen einer Folge, die repräsentativ für die normalisierte DRS ist.
Diskursrepräsentations-Datenstruktur, die repräsentativ für eine Diskurs-Eingabe ist, wobei die Diskursrepräsentationsstruktur zum Einsatz in dem computerimplementierten Verfahren nach Anspruch 1 dient und die Diskursrepräsentationsstruktur umfasst: eine Anordnung von Boxen, wobei jede Box einen Satz von Boxenelementen mit damit verknüpften Argumenten enthält und die Boxenelemente sowie die damit verknüpften Argumente eine semantische Darstellung von semantischem Inhalt der Diskurs-Eingabe enthalten, dadurch gekennzeichnet, dass der Satz von Boxenelementen als ein Vektor von Boxenelementen verkörpert ist, und die Diskursrepräsentationsstruktur des Weiteren umfasst: eine ganze Zahl, die die Anzahl von Boxenelementen in der Diskursrepräsentationsstruktur anzeigt, die eine Länge des Vektors von Boxenelementen anzeigt.
Diskursrepräsentationsstruktur nach Anspruch 13, die des Weiteren umfasst: eine Reihe, die repräsentativ für die Diskursrepräsentationsstruktur ist.
Diskursrepräsentationsstruktur nach Anspruch 13 oder 14, die des Weiteren umfasst: eine ganze Zahl, die die Anzahl von Boxen in der Diskursrepräsentationsstruktur anzeigt, die eine Länge der Anordnung von Boxen anzeigt.
Diskursrepräsentationsstruktur nach einem der Ansprüche 13 bis 15, die des Weiteren umfasst: eine Vektorabbildung, die einen Vektor von Listen von Paaren ganzer Zahlen in der Diskursrepräsentationsstruktur enthält; und eine ganze Zahl, die die Anzahl von Markierungen in der Diskursrepräsentationsstruktur anzeigt, die eine Länge der Vektorabbildung anzeigt.
Diskursrepräsentationsstruktur nach einem der Ansprüche 13 bis 16, wobei jede Box in der Anordnung von Boxen umfasst: ein Diskursrepräsentationsstruktur-Zeigerfeld, das einen Zeiger auf die Diskursrepräsentationsstruktur einschließt, die die Box enthält.
Diskursrepräsentationsstruktur nach Anspruch 17, wobei jede Box in der Anordnung von Boxen umfasst: eine ganze Zahl, die die Anzahl von Elementen in der Box anzeigt.
Diskursrepräsentationsstruktur nach Anspruch 18, wobei jede Box in der Anordnung von Boxen umfasst: einen Vektor von Element-Indizes mit einer Länge, die durch die ganze Zahl gegeben ist, die die Anzahl von Elementen in der Box anzeigt.
Diskursrepräsentationsstruktur nach einem der Ansprüche 13 bis 19, wobei jedes Boxenelement in dem Satz von Boxenelementen umfasst: ein Typ-Feld, das einen Typ Boxenelement anzeigt; und ein Feld des semantischen Typs, das einen semantischen Typ des Boxenelementes anzeigt.
Diskursrepräsentationgsstruktur nach Anspruch 20, wobei jedes Boxenelement des Weiteren umfasst: eine ganze Zahl, die die Anzahl von Boxenelement-Argumenten in dem Boxenelement anzeigt; und einen Vektor von Boxenelement-Argumenten in dem Boxenelement mit einer Länge, die durch die ganzzahlige Anzahl von Boxenelement-Argumenten angezeigt wird.
Diskursrepräsentationsstruktur nach Anspruch 21, wobei jedes Boxenelement des Weiteren umfasst: eine Folge, die repräsentativ für das Boxenelement ist.
Diskursrepräsentationsstruktur nach Anspruch 21, wobei jedes Boxenelement des Weiteren umfasst: einen Weit eines semantischen Knotens, der einen semantischen Knoten in einer Datenstruktur anzeigt, die einen semantischen Bereich darstellt, der dem Boxenelement entspricht.
Diskursrepräsentationsstruktur nach einem der Ansprüche 13 bis 23, wobei jedes Boxenelement-Argument umfasst: ein Argumenttyp-Feld, das einen Typ des Boxenelement-Argumentes anzeigt.
Diskursrepräsentationsstruktur nach Anspruch 24, wobei jedes Boxenelement-Argument umfasst: ein Argumentkennungs-Feld, das eine Kennung des Boxenelement-Argumentes einschließt.
Diskursrepräsentationsstruktur nach Anspruch 24, wobei jedes Boxenelement-Argument umfasst: ein Datenwert-Feld, das einen Datenwert enthält, der mit dem Boxenelement-Argument verknüpft ist.