Archiv der kompletten Workpackage.

HS Sprachgenerierung SoSe 2001

Dozent: Prof. Peter Hellwig

 

 

 

 

 

 

 

 

 

 

Dokumentation WP6

Phrasenlexikon und Syntax

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Autoren:

Thorsten Reichelt, 6. Fachsemester Computerlinguistik

Etienne Verleih, 6. Fachsemester Computerlinguistik


Inhaltsverzeichnis

 

1. Problemstellung und Einordnung in das Gesamtsystem... 2

2. Ergebnis. 2

2.1. Die Interface-Datei 3

2.2. Die Schablonen-Datei 4

2.3. Das Wortformenlexikon.. 5

2.4. Slots. 6

2.4.1. Auswahl der Schablone. 7

2.4.2. Unifikation. 7

2.4.3. C-Kategorien. 8

2.4.4. Fertigstellen des Satzes. 9

2.5. Umfang und Möglichkeiten des Lexikons. 10

3. Ausblick.. 11

3.1. lex und char.. 11

3.2. Lexikonstruktur.. 11

3.2.1. XML. 11

3.2.2. Namenskonventionen. 12

3.2.3. Dateizugriff 12

3.3. Grammatik.. 12

3.3.1. Morphosyntax. 12

3.3.2. Kohärenz. 13

3.3.3. Semantik. 13

4. Arbeitsaufteilung.. 13

Anhang A.. 15

 

 


1. Problemstellung und Einordnung in das Gesamtsystem

Das geplante Navigationssystem sollte erstens Weg- und zweitens Orts­be­schreibun­gen ausgeben können. Unsere Aufgabe war es, die grammatische Korrektheit dieser Ausgaben zu gewährleisten. Es sollte ein Lexikon zur Verfügung gestellt werden, mit dessen Hilfe der Composer (WP7) wohlgeformte Ausgaben erzeugen kann. Über die morphosyntaktischen und syntaktischen Merkmale hinaus waren hierfür auch semantische Aspekte wichtig. Ein Satz wie *Der Uniplatz steht neben der Heiliggeistkirche ist syntaktisch korrekt, aber es wird nicht berücksichtigt, dass ein Platz nicht stehen kann. Derartige Fehler galt es durch die Einführung geeigneter semantischer Kategorien zu vermeiden. Da semantische Zusammen­hänge dieser Art unter anderem auch von den Gruppen WP4 und WP5 zu berücksichtigen waren, entstand die Frage, in welcher Form und in den Datensätzen welcher Arbeitsgruppe derartige Informationen aufzunehmen seien.

 

Um die Ergebnisse anderer Arbeitsgruppen zu berücksichtigen, mussten mindestens folgende Begriffe in das Lexikon aufgenommen werden:

 

2. Ergebnis

Am Anfang stand die Überlegung, welche Informationen über den zu generierenden Satz dem Composer zum Zeitpunkt des Lexikonzugriffs bekannt waren. Die Lexikonstruktur sollte so ausgerichtet werden, dass über diese Informationen der richtige Satz ausgewählt werden kann. Wir nahmen an, dass dem Composer Folgendes vorliegt:

 

Um den Arbeitsaufwand in einem für das Projekt sinnvollen Rahmen zu halten, beschlossen wir, für die Konstruktion der Sätze starre Schablonen zu verwenden. Das Lexikon sollte aus drei Dateien bestehen. Die erste Datei ist ein Interface, mit dessen Hilfe der Composer die richtige Schablone auswählen kann. In der zweiten Datei befinden sich die Schablonen, in denen die Struktur von Sätzen als Kombination einzelner Satzteile (Slots) angegeben ist. Die dritte Datei schließlich enthält das Wortformenlexikon. Hier befinden sich die Wörter, die in die Schablonen eingesetzt werden können. Sie sind mit grammatikalischen Merkmalen versehen, um sie dem richtigen Slot, der diese Merkmale fordert, zuordnen zu können (Slot-Filler-Prinzip). Es folgt eine detaillierte Beschreibung dieser Dateien in der Reihenfolge ihrer angenommenen Verwendung durch den Composer.

 

2.1. Die Interface-Datei

cityguide.vlz

 

Wir beschlossen, als Ausgangspunkt für die Auswahl der richtigen Schablone die Präposition zu verwenden. Das bedeutet zwar, dass nur auf Schablonen, die eine Präposition enthalten, zugegriffen werden kann, aber für unsere Zwecke ist das völlig ausreichend.

Es handelt sich um eine einfache Textdatei, jede Zeile beinhaltet einen Eintrag. Ein solcher Eintrag hat folgende Syntax:

            präposition(modus,lo,ro) > Schablone

Dabei stehen auf der linken Seite die bekannten Daten und rechts steht die passende Schablone. Für modus kann Weg oder Ort eingesetzt werden, je nachdem, ob mit dieser Präposition eine Weg- oder eine Ortsbeschreibung generiert werden soll. Dies ist notwendig, da es Präpositionen gibt, mit denen beides möglich ist.

Für lo, also das zu lokalisierende Objekt, und ro, also das Referenzobjekt, kann jeweils entweder Obj oder Ben eingesetzt werden. Obj steht für Objekt, Ben für Benutzer. Warum diese Unterscheidung?

Das Objekt ist eine dem Composer bekannte Zeichenfolge (z.B. „Marktplatz“ oder „Heiliggeistkirche“), von der im Lexikon lediglich noch die korrekt flektierte Form nach­geschlagen werden muss. Dagegen ist die Anrede des Benutzers zusammen mit dem Verb als festes Syntagma gespeichert, um, wie später noch erklärt wird (siehe 2.3.), Flektion zu vermeiden:

            „Sie stehen hinter der Heiliggeistkirche.“

 

Während die Schablone des vorhergehende Beispielsatzes mit dem Eintrag

            hinter(Ort, Ben, Obj) > mc_double1

gefunden werden kann, sind mit der Präposition „hinter“ noch zwei weitere Varianten möglich:

            hinter(Ort, Obj, Ben) > mc_double2

hinter(Ort, Obj, Obj) > mc_doubleobj

Diese erzeugen z.B. die Sätze:

      „Hinter Ihnen steht die Heiliggeistkirche.“

            „Hinter dem Rathaus steht die Heiliggeistkirche.“

Der Composer kann also mit Hilfe der ihm bekannten Daten den Namen der korrekten Schablone aus der Interfacedatei entnehmen. Die Schablone kann dann in einer eigenen Datei nachgeschlagen werden.

 

2.2. Die Schablonen-Datei

cityguide.tpl.xml

 

Als Format für die Schablonen-Datei erschien uns XML sinnvoll, da es ersten weit verbreitet und gut unterstützt ist und sich zweitens für die Abbildung einer hierarchischen Struktur gut eignet. Folgende DTD (templates.dtd) liegt der Datei zugrunde:

 

<!ELEMENT templates       (template+)>

<!ELEMENT template       (title,general,slots)>

 

<!ELEMENT title       (#PCDATA)>

<!ELEMENT general       (CDATA)>

<!ELEMENT slots             (slot+)>

 

<!ELEMENT slot       (CDATA)>

 

<!ATTLIST slot oblig (yes|no) #REQUIRED>

 

Das oberste Element der Hierarchie ist templates, dass mindestens ein Element namens template (eine Schablone) enthalten muss. Jedes template hat genau ein Element title, ein Element general und ein Element slots. slots hinwiederum muss mindestens ein Element slot beinhalten. Jedes Element slot hat ein notwendiges Attribut oblig, das die Werte yes oder no annehmen kann.

Im Element title wird der Name der Schablone angegeben, wie ihn auch die Interface-Datei verwendet. Für die Inhalte der Elemente general und slot haben wir kein XML verwendet, da sich eine Syntax, die an die SGML-Variante des Systems PLAIN angelehnt ist, aufgrund der einfacheren Verarbeitbarkeit und Erweiterbarkeit anbot. Die beiden Elemente sind mit CDATA angegeben, um ein Parsen des Inhalts durch den XML-Parser zu verhindern. Da die gleichen Inhalte auch im Wortformenlexikon verwendet werden, werden sie später gemeinsam erläutert (siehe 2.4). Mit dem Attribut oblig wird angegeben, ob der jeweilige Slot bearbeitet werden muss, damit ein grammatikalisch korrekter Satz generiert wird.

Vor jeder Schablone befindet sich ein ausführlicher Kommentar, der den jeweiligen Ver­wen­dungs­zweck mit einem Beispiel erläutert.

 

2.3. Das Wortformenlexikon

cityguide.lex.xml

 

Auch das Wortformenlexikon haben wir in XML verfasst. Ihm liegt folgende DTD (lexicon.dtd) zugrunde:

 

<!ENTITY % body "char, unicat">

 

<!ELEMENT lexicon      (      prepositions,

                        vnps,

            verbs,

                        adverbs,

            dative_completions,

                        nouns

      )>

 

<!ELEMENT prepositions             (preposition+)          >

<!ELEMENT vnps             (vnp+)                  >

<!ELEMENT verbs                   (verb+)                 >

<!ELEMENT adverbs           (adverb+)               >

<!ELEMENT dative_completions       (dative_completion+)      >

<!ELEMENT nouns                   (noun+)                 >

 

<!ELEMENT preposition       (char, unicat+)      >

<!ELEMENT vnp                    (%body;)          >

<!ELEMENT verb                   (%body;)          >

<!ELEMENT adverb                   (%body;)          >

<!ELEMENT dative_completion      (%body;)          >

<!ELEMENT noun                   (%body;)          >

 

 

<!ELEMENT char              (CDATA)           >

<!ELEMENT unicat                  (CDATA)           >

 

 

Das oberste Element ist lexicon und enthält je genau einmal die Elemente prepositions, vnps, verbs, adverbs, dative_completions und nouns; also eine Unterteilung des Lexikons in Wortklassen. Diese enthalten jeweils mindestens ein Element ihrer Klasse: eine einzelne Wortform. Die Wortklassen-Elemente dienen als Grobgliederung des Lexikons. Sie werden letzten Endes vom Composer für die Generierung nicht benötigt, sondern sollen die Lesbarkeit erhöhen, die Bearbeitung und Suche erleichtern und linguistische Zusammenhänge deutlich machen.

Im Rahmen unseres Projektes erschien es uns nicht sinnvoll, eine eigenständige morpho­syntaktische Komponente einzubauen, da wohl alleine deren Erstellung die verfügbare Zeit in Anspruch genommen hätte. Daraus folgt, dass wir z.B. Nomen mit Artikeln und in allen benötigten Fällen abspeichern. Insofern ist es sicher nötig, die Wortklassen des Lexikons im einzelnen zu erläutern:

Wortklasse

Erläuterung

prepositions

Präpositionen wie „über“, „hinter“, oder „auf ... zu“. Genauere Untergliederung siehe Anhang A

vnps

Verb-Nominal-Phrasen.

Da innerhalb des Systems an den Benutzer gerichtete Phrasen wie „Gehen Sie“ immer gleich bleiben, speichern wir sie als festes Syntagma.

verbs

Einzelne konjugierte Verben, wie „steht“. Wird benötigt, wenn sowohl Subjekt als auch Objekt variabel sein müssen.

adverbs

Adverben. Im Augenblick benötigt als Ergänzung für Präpositionen wie z.B. „nach links“.

dative-completions

Pronominale Ergänzungen im Dativ. Optional in Sätzen wie „Rechts (von Ihnen) steht die Heiliggeistkirche.“, obligatorisch in Sätzen wie „Hinter Ihnen befindet sich die Neue Uni.“

nouns

Flektierte Nomen mit Artikeln, z.B. „des Marktplatzes“.

 
















Außer beim Element preposition setzt sich der Eintrag einer einzelnen Wortform aus den Elementen char und unicat zusammen, die beide genau einmal auftreten dürfen. Beim Element preposition sind mehrere unicat-Elemente erlaubt, um zusammengesetzte Präpositionen zu ermöglichen. Leider ist es in XML nicht möglich, genau festzulegen, wie oft ein Element auftreten darf, denn zweimal würde auch genügen.

Bei der Einführung und Verwendung des Elements char ist uns leider ein Fehler unterlaufen, der unter 3.1 erklärt wird. Gedacht war, in char die Zeichenkette zu speichern, die letztendlich so im zu generierenden Satz steht, z.B. „des Markplatzes“, wenn im Satz „Markplatz“ im Genitiv erscheinen muss.

Das Element unicat enthält, wie das Element slot der Schablonen, eine an PLAIN an­ge­lehnte Syntax, die im nächsten Abschnitt (2.4) erklärt wird.

 

2.4. Slots

Die Slots sind in diesem System das zentrale Element zum Generieren eines Satzes. Ein Slot in einer Schablone steht für ein einzelnes Satzglied, das manchmal nur ein Wort umfasst. Die Reihenfolge der Slots in der Schablone entspricht der Reihenfolge der Satzglieder im zu generierenden Satz. An einem Beispiel wollen wir vorführen, wie der Composer mittels einer Schablone einen Satz generieren kann.

2.4.1. Auswahl der Schablone

Angenommen, dem Composer liegen folgende Daten vor:

 

Mit den ihm bekannten Angaben hat der Composer den Titel der zu verwendenden Schablone in der Interface-Datei nachgeschlagen und die Schablone aus der Schablonen-Datei gelesen:

 

<template>

  <title>mc_single2</title>

  <general>type[mc] mode[statement]</general>

  <slots>

    <slot oblig="yes">cat[prep_single]</slot>

    <slot oblig="yes">cat[verb] person[3] number[C] sem[sich befinden] sem[C]</slot>

    <slot oblig="yes">cat[noun] case[nom] number[C] sem[C]</slot>

  </slots>

</template>

 

Im General-Tag werden allgemeine grammatikalische Informationen über den Satz gegeben. Hier wird z.B gesagt, dass es sich um einen Haupt- und Aussagesatz handelt (eine detaillierte Auflistung aller Kategorien befindet sich im Anhang A). Das general-Tag wird im Augen­blick für die Satzgenerierung nicht benötigt; uns erschien es jedoch sinnvoll, an dieser Stelle linguistische Informationen speichern zu können.

 

2.4.2. Unifikation

Der Composer muss nun die grammatikalischen Kategorien der Präposition und aller Objekte (obj) im Wortformenlexikon nachschlagen. Dies geschieht über die bei jedem Eintrag vorhandene Kategorie lex (siehe aber auch 3.1). Dabei findet er für „zu Ihrer Linken“ den Eintrag:

<preposition>  <char>zu Ihrer Linken</char>  <unicat>lex[zu Ihrer Linken] cat[prep_single]</unicat></preposition>

Die Einträge in unicat müssen mit einem der Slots in der Schablone unifizierbar sein. Dabei müssen gleichnamige Kategorien gleiche Werte haben. Es dürfen aber sowohl in slot als auch in unicat Mehrinformationen enthalten sein. Im Beispiel würde die Präposition mit dem ersten Slot unifizieren und ihn somit füllen. Der Satz beginnt also mit „[Zu Ihrer Linken] [...] [...]“.Als nächstes muss der Composer unter „Rathaus“ im Lexikon nachschlagen. Dabei findet er mehrere alternative Einträge. Alle diese Einträge müssen wie beschrieben mit den Slots verglichen werden. Wenn dabei mehrere der gefundenen Einträge unifizierbar sind, kann ein beliebiger davon gewählt werden.

 

Um Redundanz zu vermeiden, ist es möglich, einer Kategorie mehrere, durch Kommata getrennte Werte zu geben. Ein Komma bedeutet ein logisches Oder, das heißt, einer der Werte muß mit der Vorgabe unifizieren. So kommt es, dass in unserem Beispiel folgender Eintrag für „Rathaus“ ausgewählt werden kann:

<noun> 

  <char>das Rathaus</char>

  <unicat>(lex[Rathaus] cat[noun] number[singular] case[nom, acc] gender[neut] sem[Gebäude])

  </unicat>

</noun>

 

Die im Satz erscheinende Zeichenfolge (in char angegeben) ist für Nominativ und Akkusativ identisch, deshalb sind in der Kategorie case beide Möglichkeiten angegeben. Dieser Lexikon­eintrag unifiziert also mit Slot drei. Der erzeugte Satz heißt jetzt: „[Zu Ihrer Linken] [...] [das Rathaus]“.

 

2.4.3. C-Kategorien

Zusätzlich zu den Kategorien, mit denen unifiziert worden ist, erscheinen im zweiten und dritten Slot unseres Beispiels noch Kategorien, denen der Wert C zugewiesen ist. Wenn durch Unifizierung der übrigen Kategorien ein passender Lexikoneintrag gefunden wurde, wird für die Kategorien mit einem C der Wert jenes Lexikoneintrags eingesetzt. In unserem Beispiel wird also im dritten Slot number[C] zu number[singular] und sem[C] zu sem[Gebäude].

 

Diese Kategorien sind vorhanden, um Kongruenz zwischen den Slots herzustellen. Es muß zum Beispiel sichergestellt werden, dass Verb und Nomen im Numerus übereinstimmen. Um dies zu erreichen, müssen letztendlich alle gleichnamigen Kategorien, die ein C enthalten, in allen Slots die gleichen Werte haben.

 

2.4.4. Fertigstellen des Satzes

Nachdem alle bekannten Daten verwendet und die entsprechenden Slots, hier der erste und der dritte, gefüllt worden sind, müssen die noch leeren Slots, hier der zweite, bearbeitet werden. Dazu muss im Wortformenlexikon ein Eintrag gefunden werden, der mit den Kategorien des Slots unifiziert. Der Unterschied zur Bearbeitung der anderen Slots besteht hauptsächlich darin, dass die Suche nicht einfach über die Kategorie lex erfolgen kann. Wie der Composer im Lexikon nach dem korrekten Eintrag sucht, ist implentierungsabhängig. Wahrscheinlich ist es am günstigsten, zuerst alle Lexikoneinträge mit dem entsprechenden Wert für die Kategorie cat zu finden, und dann die Auswahl durch die Unifizierung der weiteren Kategorien einzuschränken. Weiterhin gelten dieselben Unifizierungsregeln wie für die anderen Slots.

 

Durch die Verwendung von cat[verb], person[3] und sem[sich befinden], also der von Anfang an feststehenden Werte, werden für den zweiten Slot unter anderem folgende Lexikoneinträge ausgewählt:

 

1)

<verb>

  <char>steht</char>

  <unicat>lex[stehen] cat[verb] person[3] number[singular] tense[present] sem[sich befinden, Gebäude, kleines Objekt]</unicat>

</verb>

 

2)

<verb>

  <char>stehen</char>

  <unicat>lex[stehen] cat[verb] person[3] number[plural] tense[present] sem[sich befinden, Gebäude, kleines Objekt]</unicat>

</verb>

 

3)

<verb>

  <char>befindet sich</char>

  <unicat>lex[sich befinden] cat[verb] person[3] number[singular] tense[present] sem[sich befinden, Gebäude, Straße, Platz, Gewässer, kleines Objekt]</unicat>

</verb>

 

Besonderer Erwähnung bedarf das zweimalige Erscheinen der Kategorie sem im Verb-Slot unseres Beispiels. Dabei hat das erste sem einen festen Wert, nämlich „sich befinden“, während das zweite sem als Wert ein C hat. Mittels des ersten sems wird sichergestellt, dass im zu generierenden Satz nur Verben erscheinen dürfen, die auch den Eintrag sem[sich befinden] vorweisen können, also z.B. Verben wie „steht“ oder „befindet sich“. Das zweite sem funktioniert wie alle anderen C-Kategorien. In unserem Beispiel werden also Werte wie „Gebäude“ oder „Platz“ eingefügt. Dann wird es mit den sems anderer Slots, hier des Objekt-Slots, verglichen. Dies wird nötig, damit die inhaltliche Kongruenz gesichert wird, z.B. können Plätze nicht stehen.

 

Nach der Anwendung der oben beschriebenen C-Kategorien kann man also die Auswahl des richtigen Verbs weiter einengen. In diesem Fall wird durch das Objekt „Rathaus“ vorgegeben, dass sich das Verb im Singular befinden muss, folglich bleiben nur noch die Möglichkeiten 1) und 3) übrig. Die Wahl zwischen diesen Einträge steht dem Composer frei. Der Satz kann also letztendlich lauten:

„[Zu Ihrer Linken] [steht] [das Rathaus].“ oder „[Zu Ihrer Linken] [befindet sich] [das Rathaus].“

 

2.5. Umfang und Möglichkeiten des Lexikons

Im Augenblick ermöglichen unsere Templates einfache Hauptsätze. Alle generierbaren Sätze beinhalten eine Präposition bzw. Präpositionalphrase, ein Verb und maximal zwei Objekte. Auch diskontinuierliche Präpositionen sind möglich (siehe Template mc_prep3). Bei den Verben haben wir versucht, Variationsmöglichkeiten anzubieten. Im Augenblick nicht enthalten sind Möglichkeiten zur Steuerung der Kohärenz zwischen mehreren Sätzen. Auch inhaltliche Unterordnung und Koordination mit Hilfe von Konjunktionen und Nebensätzen ist nicht möglich. Dies hätte den Rahmen des Projekts gesprengt.

 

Der Zugriff auf das Lexikon erfolgt im Augenblick über die Präpositionen (siehe 2.1). Es sind jedoch auch andere Zugriffswege denkbar. Mit einer anders gestalteten Interface-Datei könnte man z.B. auch über die Verben die richtige Schablone wählen.

 

Wir haben anhand einer Liste von WP2 sämtliche Straßen und Plätze der Heidelberger Altstadt aufge­nommen, zusätzlich Teile von Bergheim und wichtige Zufahrtsstraßen. Zusätzlich zu den von WP8 bearbeiteten Sehenswürdigkeiten haben wir versucht, wichtige Navigationspunkte Heidelberger Altstadt zu berücksichtigen.

 

3. Ausblick

3.1. lex und char

Wie schon gesagt, ist uns bei den Kategorien lex und char der Wortformen-Datei ein Fehler unterlaufen. Gedacht war, dass der Composer ein Wort im Lexikon über den Eintrag lex findet, also in lex die Grundform des Wortes steht. In der Kategorie char dagegen sollte die Zeichenfolge, wie sie im Satz erscheinen soll, stehen. Erst nachdem wir diskontinuierliche Präpositionen eingeführt hatten, stellten wir fest, dass dies in dieser Form nicht funktioniert:

 

<preposition>

  <char>auf zu</char>

  <unicat>lex[auf] cat[dyn_dc] part[1]</unicat>

  <unicat>lex[zu] cat[dyn_dc] part[2]</unicat>

</preposition>

 

Da der Composer nach lex suchen sollte, würde er in diesem Fall die Präposition „auf zu“ nicht finden. Die einfachste Lösung des Problems ist es, lex und char überall zu vertauschen. Das hat zusätzlich den Vorteil, dass sich der Suchtext nicht mehr in der noch extra zu par­sen­den unicat-Kategorie befindet. Der obige Eintrag würde dann wie folgt aussehen:

 

<preposition>

  <lex>auf zu</lex>

  <unicat>char[auf] cat[dyn_dc] part[1]</unicat>

  <unicat>char[zu] cat[dyn_dc] part[2]</unicat>

</preposition>

 

3.2. Lexikonstruktur

3.2.1. XML

Wir könnten uns vorstellen, die Struktur unseres Lexikons in verschiedenen Punkten zu verbessern. Es wäre denkbar, das Lexikon vollständig in XML abzufassen und nicht innerhalb der Kategorien general, unicat und slot ein völlig anderes Format zu verwenden. Wir haben das bisherige Format aus verschiedenen Gründen verwendet:

 

Die Vorteile von XML dagegen wären:

 

Zusätzlich könnte man in die XML-Struktur noch weitere Informationen einbinden. So steht im Augenblick vor jeder Schablone ein Kommentar, der über deren Verwendungszweck informieren soll. Diese Kommentare sind recht uneinheitlich, da sie von zwei Personen verfasst wurden. Dies könnte man durch das Einfügen eines Informationsblocks in die XML-Struktur vereinheitlichen; ein solcher Block könnte zum Beispiel Autor, Verwendungszweck und Datum der letzten Änderung beinhalten.

 

3.2.2. Namenskonventionen

Um die Lesbarkeit zu verbessern und die Zusammenarbeit mehrerer Autoren zu ermöglichen, sollte man Namenskonventionen einführen. Momentan sind vor allem die Namen der Schablonen und die Werte der Kategorie cat unübersichtlich und teilweise nicht nach­voll­zieh­bar.

 

3.2.3. Dateizugriff

Das Parsen einer XML-Datei ist eine zeitaufwendige Angelegenheit. Da das Lexikon einer natürlichen Sprache sehr groß werden kann, muss man sich Gedanken um effizienten Dateizugriff machen. In einer der Projektsitzungen wurde ein Lexikoncompiler vor­ge­schlagen. Das halten wir für eine gute Idee. Das Lexikon könnte dann in XML leicht ge­schrieben und geändert werden, anschließend würde es in eine auf Maschinenlesbarkeit optimierte Form übertragen.

 

3.3. Grammatik

3.3.1. Morphosyntax

Die wichtigste Ergänzung im Grammatikbereich wäre die Einführung einer Morpho­logie­komponente. Im Augenblick enthält das Wortformenlexikon Substantive, für die fünf Ein­träge nötig sind. Um das Lexikon nicht ins Unendliche anwachsen zu lassen, empfiehlt sich für größere Projekte dringend die Automatisierung von Flektion und Konjugation. Auch das Abspeichern von Wortkombinationen wie „zum Rathaus“ oder „Gehen Sie“ ist dann nicht mehr ratsam. Gut vorstellbar wäre eine auf Schablonen basierende Morphologiekomponente wie im System PLAIN.

 

3.3.2. Kohärenz

Um Texte zu produzieren, die möglichst nah an der natürlichen Sprache sind, bedarf es Mechanismen wie Pronomen und der Koordination und Subordination von Sätzen. Dies ist nur in Zusammenarbeit mit dem Textplaner zu erreichen, in den Schablonen müssen jedoch geeignte Mechanismen geschaffen werden. Eine Realisierungsmöglichkeit für Nebensätze wäre es z.B., in einer Schablone auf weitere Schablonen zu verweisen, die Slots für den gewünschten Nebensatz enthalten. Die Koordination von Sätzen wird durch einen optionalen Slot am Anfang der Schablone erreicht, durch den eine Konjunktion eingefügt werden kann. Statt eines Substantives ein Pronomen einzufügen, ist syntaktisch gleichfalls kein Problem, da es die gleichen grammatikalischen Merkmale besitzt. Die Schwierigkeit ist es jedoch, all diese Mechanismen richtig anzuwenden. Welche Hilfsmittel hierfür in das Lexikon aufgenommen werden sollten, muss gemeinsam mit dem Textplaner erarbeitet werden.

 

3.3.3.  Semantik

Während der Arbeit an dem vorliegenden Lexikon ist uns klar geworden, dass die Re­präsentation von semantischen Merkmalen alles andere als einfach ist. Die wenigen semantischen Merkmale, die wir nach vielen Überlegungen und einigen Korrekturen in unser Lexikon aufgenommen haben, werden für die Generierung eines größeren natürlichsprachigen Textes mit Sicherheit nicht ausreichen. Ob und wie die Repräsentation von Weltwissen in einem Syntaxlexikon möglich ist, ist uns nicht klar. Geeigneter wären wahrscheinlich Systeme, die mit frei definierbaren Relationen zwischen Objekten arbeiten. Insgesamt gehört die Repräsentation von Semantik wohl eher in den Arbeitsbereich des Textplaners. Auch hier jedoch sind Hilfestellungen im Syntaxlexikon möglich.

 

4. Arbeitsaufteilung

Abschließend einige organisatorische Details. Die Arbeit wurde größtenteils im Team durchgeführt, dies gilt vor allem für die Struktur des Lexikons und die hier vorliegende Dokumentation. Die Schablonen der Ortsbeschreibungen wurden von Etienne Verleih und die Schablonen der Wegbeschreibungen von Thorsten Reichelt erstellt. Die zugehörigen Präpositionen und Verben hat der jeweilige Verfasser der Schablone aufgenommen. Die Straßen, Plätze und Objekte der Heidelberger Altstadt haben wir zu gleichen Teilen be­ar­beitet.


Anhang A

Die unicat-, general- und slot-Kategorien

 

Kategorie

Funktion

Wert

Erklärung des Werts

case

Deklinationsmerkmal Kasus bei Nomen

nom, gen, dat, acc

Nominativ, Genitiv, Dativ und Akkusativ

zudat

Dativ in Verbindung mit „zu“. Aufgenommen, um morphosyntaktische Schwierigkeiten bei „zu+dem“ zu vermeiden. Beispiel: „zum Rathaus“

cat

Alle Wörter sollten so in Kategorien aufgeteilt werden, dass man durch geregelte Verknüpfung (Schablonen) der Kategorien wohlgeformte Sätze erhält.

dyn1

Präpositionen vor Akkusativobjekten. Beispiel: „Gehen Sie in die Kirche.“

dyn2

Präpositionen vor Dativobjekten mit „zu“, momentan nur „bis zu“. Für Kongruenz siehe auch case[zudat]. Beispiel: „Gehen Sie bis zur Kirche.“

dyn_dc

Diskontinuierliche Präpositionen vor Akkusativobjekt. Beispiel: „Gehen Sie auf die Kirche zu.“ Siehe auch Kategorie part.

postprep

Präpositionen nach einem Akkusativobjekt. Beispiel: „Gehen Sie die Hauptstraße entlang

dyn_gen

Präpositionalphrasen vor einem Genitivobjekt. Beispiel: Gehen Sie in Richtung des Rathauses.

dyn_nach

Enthält nur „nach“, das im Gegenteil zu anderen Präpositionen nicht mit einem Objekt, sondern mit Worten der Kategorien adv_dir1 und adv_dir2 kombiniert werden kann. Beispiel: „Gehen Sie nach rechts.“

prep_single

Ortsbestimmungen, in der das RO schon enthalten ist. Beispiel: „Zu Ihrer Rechten sehen Sie das Rathaus.“

prep_double1, prep_double2

Beinhalten Präposition, die örtliche Beziehungen der Art „neben” oder „auf” zwischen zwei Dingen ausdrückt; prep_double2 funktioniert nur, wenn der Benutzer das Subjekt ist.

Beispiel:  „Sie stehen auf dem Uniplatz.”

adv_dir1, adv_dir2

adv_dir1 enthält „links“ und „rechts“, adv_dir2 enthält „oben“ und „unten“. Die Aufteilung erfolgte, da in der Schablone mc_single1 „oben“ und „unten“ nicht funktioniert.

Beispiel: „Rechts befindet sich der Neckar.“

verb

Ein einzelnes konjugiertes Verb, im Ggs. zur vnp. Bsp: „Links steht die Neue Uni.“

vnp

Eine Kombination aus einem Personalpronomen und einem konjugierten Verb, z.B. „Gehen Sie“. Wird immer dann verwendet, wenn der Benutzer genannt wird.

von_user

Nennt den Benutzer im Dativ, bei Adverbien in Verbindung mit „von“: „Links von Ihnen steht das Rathaus.“

pron_user

Nennt den Benutzer im Dativ:  „Neben Ihnen befindet sich der Brunnen.“

noun

Ein dekliniertes Nomen mit Artikel oder „zu“. Bsp.: „zum Rathaus“

gender

Deklinationsmerkmal Genus bei Nomen

masc, fem, neut

Maskulin, Feminin und Neutrum

 

lex

Unter dieser Kategorie soll das Wort nachgeschlagen werden können.

Grundform des Wortes

s. Funktion

mode

Gibt den Modus des Satzes an. Im Deutschen von Verb und Satzstellung abhängig, deshalb bei general, verb und vnp verwendet.

statement, imperative

 

number

Flektionsmerkmal Numerus bei Verben, Nomen und Pronomen.

singular, plural

 

part

Kontrollstruktur bei diskontinuierlichen Präpositionen.

1, 2

1 für den ersten, 2 für den zweiten Teil der Präposition. In der Schablone müssen dann beide Teile einzeln aufgelistet werden. Beispiel: „Gehen Sie auf die Kirche zu

person

Flektionsmerkmal Person bei Verben und Personalpronomen.

1, 2, 3

 

sem

Speichert semantische Merkmale, im Augenblick zu Verben und Nomen. Siehe auch Erklärung bei 2.4.4.

sich befinden, wahrnehmen, bewegen

Für Verben

Gebäude, Straße, Platz, Gewässer, kleines Objekt

Für Nomen. Einteilung von WP4 und WP5 übernommen.

tense

Flektionsmerkmal Tempus bei Verben. Bietet bisher nur Zusatzinformationen

 

 

type

Gibt im general-Tag an, ob es sich um eine Schablone für einen Haupt- oder Nebensatz handelt

mc

Hauptsatz (main clause)

sc

Nebensatz (subordinate clause)