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.4.4. Fertigstellen des Satzes
2.5. Umfang und Möglichkeiten des Lexikons
Das geplante Navigationssystem sollte erstens Weg- und zweitens Ortsbeschreibungen 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 Zusammenhä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:
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.
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 nachgeschlagen 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.
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 Verwendungszweck mit einem Beispiel erläutert.
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 morphosyntaktische 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 angelehnte Syntax, die im nächsten Abschnitt (2.4) erklärt wird.
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.
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 Augenblick für die Satzgenerierung nicht benötigt; uns erschien es jedoch sinnvoll, an dieser Stelle linguistische Informationen speichern zu können.
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 Lexikoneintrag unifiziert also mit Slot drei. Der erzeugte Satz heißt jetzt: [Zu Ihrer Linken] [...] [das Rathaus].
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.
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].
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 aufgenommen, 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.
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 parsenden 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>
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.
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 nachvollziehbar.
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 vorgeschlagen. Das halten wir für eine gute Idee. Das Lexikon könnte dann in XML leicht geschrieben und geändert werden, anschließend würde es in eine auf Maschinenlesbarkeit optimierte Form übertragen.
Die wichtigste Ergänzung im Grammatikbereich wäre die Einführung einer Morphologiekomponente. Im Augenblick enthält das Wortformenlexikon Substantive, für die fünf Einträ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.
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.
Während der Arbeit an dem vorliegenden Lexikon ist uns klar geworden, dass die Reprä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.
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 bearbeitet.
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) |