rt-gramm_frwk_chi.org

\VerbatimFootnotes

\pagenumbering{gobble}

\tableofcontents \pagenumbering{roman} \listoffigures \renewcommand*\lstlistlistingname{Auflistungen} \renewcommand*\lstlistingname{Auflistung} \lstlistoflistings \listoftables

Einleitung

\pagenumbering{arabic} Diese Arbeit beschreibt und evaluiert eine mit »Grammatical Framework« (GF) implementierte sogenannte Ressourcen-Grammatik für das Chinesische. In einer Ressourcen-Grammatik werden durch Linguisten syntaktische und morphologische Besonderheiten einer Sprache samt lexikalischen Einträgen hinterlegt, was wiederum einem Programmierer ermöglicht, ohne spezifische Sprachkenntnisse syntaktisch korrekte chinesische Sätze zu bilden. Außerdem sind die Funktionen innerhalb aller Ressourcen-Grammatik, die eine Syntax generieren, identisch, sodass ein konsistenter Zugang über Sprachen hinweg vorhanden ist.[fn::Software-technisch handelt es sich hier um eine API, Application Programmer’s Interface.REFTODO] Eine Hinführung zum Thema GF sowie in die Nutzung der »Resource Grammar Library« (RGL) von GF wird den Evaluationsprozess nachverfolgbar machen.

Zwischen Formalismus und Programmiersprache

Zweckgerichtetheit (special purpose)

GF ist keine Programmiersprache mit allgemeinem Anwendungszweck (general purpose [programming] language, GPL), sondern bedient den speziellen Zweck (special purpose), multilinguale Grammatiken zu erstellen. Zu diesem Zweck bietet GF verschiedene Eigenschaften was Aufbau und Infrastruktur anbelangt, welche wiederum von GPLs, wie Java, C++, Haskell und ML, sowie von typen-theoretischen Beweisassistenten, wie etwa ALF[fn:: Was die Namensgebung von GF und auch das Konzept der abstrakten Syntax angeht, so ist ALF (Another Logical Framework) sozusagen ein direkter Vorfahre von GF. Cf. \cite[22]{ranta_grammatical_2011}] und Agda[fn:: Der Algorithmus zur Prüfung der Typen in GF ist identisch zu dem in Agda. Cf. \cite[74]{angelov_mechanics_2011}, \cite[8]{maenpaa_type_1999}], inspiriert sind. Zwei der wichtigsten Punkte unter diesen Eigenschaften sind, dass zum einen der Komplexität natürlicher Sprachen Rechnung getragen wird (via Funktionen und einem statischen Typ-System), und zum andern, dass einmal formulierte Informationen einer Sprache leichthin abrufbar und damit wiederverwendbar sind (via Modularisierung, Vererbung und Instanzierung). So ist das Ergebnis der Arbeit mit GF zwar eine multilinguale Grammatik, die einen einfach zu interpretierender grammatischer Formalismus darstellt, aber der Weg dorthin ist nicht trivial und geprägt von vielfältigen Rechenabläufen (computations) und Infrastrukturangeboten. Zur Kategorisierung als special purpose language, siehe \cite[253]{ranta_grammatical_2011}, \cite[1]{ranta_grammatical_2004}.

Turing-unmächtig

Ein interessanter Aspekt der Charakterierung von GF als sowohl grammatischer Formalismus als auch Programmiersprache ist desweiteren, dass der angestrebte Formalismus die Mächtigkeit der Programmiersprache beschränkt: Würde GF Turing-mächtig sein, dann wäre nicht sichergestellt, dass eine Sprache mit der dazugehörigen GF-Grammatik gleichermaßen geparst als auch generiert werden könnte; der Formalismus sichert die Umkehrbarkeit (TODO: mapping between trees and strings (as tuples) is compositional and thereby homomorphic, reversible). TODO: In Einleitung damit? – zu abstrakt, lieber nach Exposition oder Appendix (gehört ja eh zu Appendix (– nur supplementärer Gegenstand der Arbeit))

Experimentierstoff

Die nun verwendeten Beispiel-Grammatiken liegen (wie auch dieser Text) in einem öffentlich zugänglichen Archiv und stehen so zum eigenen Experimentieren bereit.[fn:: https://github.com/salamynder/mag15 . Siehe auch zur Installation von GF auf verschiedenen Systemen: http://www.grammaticalframework.org/download/index.html . GF_LIB_PATH unter Windows setzen: http://www.grammaticalframework.org/~inari/gf-windows.html . Die von mir verwendeten GF-Version ist TODO.]

Motivation

GF ist sowohl ein Grammatik-Formalismus als auch eine zweckgerichtete (special purpose) Programmiersprache zum Programmieren multilingualer Applikationsgrammatiken. Der Aspekt der Multilingualität bedeutet für die Erstellung einer Applikationsgrammatik, dass immer zwischen sog. konkreten Grammatiken und abstrakten Grammatiken unterschieden wird. Konkrete Grammatiken werden für die Übersetzung in und aus bestimmten Sprachen erstellt; abstrakte Grammatiken dienen als Dreh- und Angelpunkt für konkrete Grammatiken, indem der Programmierer mit der abstrakten Grammatik ein semantisches Modell vorgibt, an das die konkreten Grammatiken gebunden sind. Dieses semantische Modell bezieht sich auf eine bestimmte Sprachdomäne und somit auch auf einen bestimmten Anwendungsfall, der sich software-technisch als Applikation, also als ein Programm bzw. eine Anwendung für einen bestimmten Zweck, manifestiert.

Zum Beispiel könnte unser Vorhaben eine Applikationsgrammatik für einen Tierpark sein, der an bestimmten Aussichtsplätzen und auf gewissen Endgeräten, wie etwa Touchscreens, eine Applikation bereitstellt, die Informationen zu den Tieren in verschiedenen Sprachen bietet. Im Kontext der Sprachdomäne Tierpark wäre es dann klar, dass es sich bei einem Strauß nicht um einen Blumenstrauß, sondern vielmehr um einen Vogelstrauß handeln muss. Der Programmierer als Domänenexperte hat dann die Verantwortung, den Sachverhalt, dass es sich bei dem Strauß um ein Tier handeln soll, in entsprechender Weise in der Applikationsgrammatik zu hinterlegen. Etwas genauer heißt das, der Domänen-Experte stellt sicher, dass das Zeichen für Vogelstrauß nur mit Aktionen, die einen Vogelstrauß auch faktisch charakterisieren, wie etwa »fressen«, »schnell laufen« oder »nicht fliegen«, kombiniert werden kann. Im folgenden Abschnitt wird dieser Sachverhalt konkret mittels GF-Code-Ausschnitten illustriert.

Die Einzelheiten zu den verschieden Begrifflichkeiten der Grammatiken werden ausführlicher im GF-Expositions-Kapitel abgehandelt. In diesem Kapitel geht es dagegen vornehmlich darum, einen knappen Einblick in die Leistungsfähigkeit des GF-Systems, insbesondere auch der »Resource Grammar Library« (RGL), zu geben.

Linearisierungs-Regeln

Betrachten wir den Satz »der Strauß frißt Beeren«, dann können wir diesen folgendermaßen in einer konkreten GF-Grammatik für das Deutsche formalisieren:

#+CAPTION[ZooGer]: Ausschnitt aus der konkreten Grammatik ZooGer.gf (./example-code/Zoo/)

In diesem Ausschnitt der konkreten Grammatik sind die Linearisierungs-Regeln der konkreten Grammatik in den Zeilen 2–4 sowie 6 abgebildet, welche vom GF-Compiler verarbeitet werden. Dagegen sind Zeile 1 und 5 – mit zwei Bindestrichen (\inlst$–$) einleitend markiert und bis zum Ende der Zeile gültig – Kommentar-Zeilen, die vom Compiler ignoriert werden.

Zu linearisieren bedeutet im GF-Kontext, Zeichenketten herzustellen. Zeichenketten sind die einfachste Datenstruktur in GF und stehen immer zwischen nicht-typographischen Anführungszeichen, i. e. \inlst$”“$. Das allgemeine Schema für Linearisierungs\hyp{}-Regeln ist:

Das Schema untergliedert Regeln zunächst in einen Bereich links und rechts vom Gleichheitszeichen, indem es die Abkürzungen LHS (left hand side) und RHS (right hand side) einführt. Auf der LHS wird dann als erstes ein Regelname und im Anschluss können potentielle Argumentbezeichner vergeben werden. Aus Konvention beginnt der Regelname mit einem Großbuchstaben und Argumentnamen werden komplett klein geschrieben.

Mit der Angabe von Argumenten sind diese als Variablen auf der RHS und damit in der Definition der Regel nutzbar. Das bedeutet nichts anderes, als dass eine Regel-Definition in GF sich so verhält, wie wir es von einer Funktions-Definition in der Mathematik erwarten würden: So ist $f(x) = x+1$ eine Funktion $f$, die auf der LHS in Abhängigkeit von der Argument-Variable $x$ gestellt wird, was wiederum das $x$ auf der RHS in $x+1$ als Platzhalter (Variable) bestimmt, sodass z. B. $f(1) = 1+1 = 2$ evaluiert werden kann.[fn::In der Theorie der Programmiersprachen wird auch unterschieden zwischen formalen (Argument-Variablen) und aktuellen Parametern (Werten für $x$) einer Funktion, um auch jeweils die abstrakte Platzhalterfunktion $x$ in $f(x) = x + 1$ respektive das konkrete Einsetzen von Werten für diesen Platzhalter zu beschreiben. (Vgl. \cite[300]{mehlhorn_grundlagen_2013}.) Dagegen verwende ich nun die Begriffe Parameter und Argument synonym für beide Beschreibungen, weil im Kontext leicht disambiguiert werden kann und auch weil im Lambda-Kalkül \citep[1]{nederpelt_type_2014} der formale Parameter als Variable beschrieben wird, was wiederum den hier gewählten Term Argument-Variable motivierte.] Der Unterschied ist nur, dass in GF-Notation Argument-Variablen nicht in Klammern, sondern durch Nebenstellung (Juxtaposition) mit der Funktion assoziiert werden.

Man beachte außerdem, dass die Reichweite (scope) der Argument-Variablen sich nur auf eine bestimmte Regel erstreckt. – Verschiedene Regeln mit identisch benannten Argument-Variablen sind also zulässig. Auch sollte klar sein, dass über die Benennung einer Argument-Variablen frei entschieden werden darf.

Die Regeln sind unterteilt in konstante Regeln (\inlst$VStrauß, Fressen, Beere$) und solche Regeln, die diese Konstanten untereinander in Beziehung setzen (\inlst$Pred$).[fn::Für konstante Regeln bzw. Konstanten gibt es auch eine Analogie in der Mathematik. Denn Konstanten sind nämlich auch Funktionen, aber solche, die nicht in Abhängigkeit von einem Argument stehen, und daher immer einen konstanten Wert produzieren.] Von Zeile 2–4 haben wir insgesamt drei Regeln, die in Anführungszeichen Zeichenketten definieren, welche wir für den angestrebten Satz benötigen. So definiert etwa die Regel namens \inlst$VStrauß$ mittels des Gleichheitszeichens eine Zeichenkette, \verb+”der Strauß”+, mit zwei Tokens, »der« und »Strauß«.[fn::Linguistisch betrachtet ist es analytisch nicht zielführend, Artikel und Nomen in eine einzige Regel zu packen. Um das Beispiel jedoch maximal zu vereinfachen, wird hier (vorerst) so vorgegangen.] Die nächsten beiden Regeln, \inlst$Fressen$ und \inlst$Beere$, definieren wiederum jeweils eine Zeichenkette, wobei jede dieser Ketten diesmal nur aus einem Token besteht, i. e. \inlst$”frißt”$ respektive \inlst$”Beeren”$.

Die Pred-Regel[fn:: Abkürzung für Prädikation (engl. predication). Als Grundlage von jeglicher Form von Aussagen spezifiziert die Prädikation einen Gegenstand oder setzt diesen in Beziehung zu anderen. Vgl. \cite[542]{busmann_lexikon_2008}.] in Zeile 6 ist nun dazu da, andere Regeln zu kombinieren. Bedingung für eine Kombination ist, dass – im Gegensatz zu den vorigen Regeln – \inlst$Pred$ andere Regeln als Argumente nehmen kann. Die Argumente werden auf der LHS hinter dem Regelnamen eingesetzt und demnach auch auf der RHS mittels des Zeichenketten-Konkatenations-Operators (\inlst$++$) kombiniert.

Die Benennung der Argumente im Beispiel ist bewusst an die konstanten Regeln (Konstanten) angelehnt, um nahezulegen, welche Konstante für welches Argument im Kontext des gesuchten Satzes eingesetzt werden sollte.[fn:: Über die abstrakte Grammatik wird dann strikt reglementiert, welche Argumente (und dadurch auch, in welcher Folge) eine Regel bzw. Funktion akzeptiert. Das heißt, wir können prinzipiell genau festlegen, was z. B. Subjekt und was Objekt eines Satzes sein darf. Siehe Exposition/astcat-intro.] So können wir \inlst$Pred$ sozusagen händisch evaluieren, indem wir die Konstanten an Stelle der Argumente in \inlst$Pred$ einsetzen:

#+CAPTION[EvalPred]: Evaluation von Pred mit Konstanten ergibt dessen Linearisierung

-- Die Pred-Regel als Ausgangspunkt:
Pred vstr    fres    beer  = vstr    ++ fres    ++ beer ;

-- Einsetzen der Konstanten in LHS und demnach auch in RHS:
Pred VStrauß Fressen Beere = VStrauß ++ Fressen ++ Beere ;

-- Evaluation der Konstanten auf RHS:
Pred VStrauß Fressen Beere = "der Strauß" ++ "frißt" ++ "Beeren" ;

-- Evaluation von (++),
-- i. e. Verkettung der Zeichenketten mit einem Leerzeichen:
Pred VStrauß Fressen Beere = "der Strauß frißt Beeren" ;

Die Evaluation in Auflistung EvalPred macht also deutlich, dass wir mit der Pred-Regel angewendet auf die Konstanten in der Tat den einfachen Satz »der Strauß frißt Beeren« erzeugen können. Beobachten wir außerdem die Abhängigkeit, in der Pred von seinen Argumenten steht (Abbildung ZooPred-vt), so können wir zeigen, inwiefern Linearisierung als Verflachung, also als Einebnung von Hierarchien, zu verstehen ist. #+CAPTION[ZooPred-vt]: Hierarchie der Linearisierungs-Regeln von ZooGer.gf (Baumstruktur)

Pred bildet in Abhängigkeit seiner Argumente eine Hierarchie aus, die jedoch durch das Linearisieren in eine Zeichenkette eingeebnet wird. Während Regeln also Abhängigkeiten modellieren können, sind Zeichenketten nur dazu in der Lage, Informationen sequentiell festzuhalten. Linearisierung ist daher zu definieren als die Abbildung (Mapping) von Baum-Strukturen in Zeichenketten. Dass zudem dieser Linearisierungs-Prozess umkehrbar ist (was durch den GF inhärenten Formalismus gesichert ist), dass also durch die GF-Grammatik eine Zeichenkette in ihre Baumrepräsentation (ein semantisches Modell aus Regeln) überführt (geparst) werden kann, das ermöglicht schließlich Übersetzung im GF-System (siehe parse-lin).

Interlingua

Die Krux an der Feststellung, dass wir auf der einen Seite Regeln als Baumstrukturen und auf der andern Seite Zeichenketten haben, ist nun, dass wir dieselben Regeln in anderen Grammatiken wiederverwenden können, um aber andere Zeichenketten zu produzieren. Zur Demonstration nehmen wir daher eine zweite Grammatik hinzu, die eine Übersetzung unseres Satzes in Chinesische bereitstellt.

#+CAPTION[ZooChi]: Ausschnitt aus der konkreten Grammatik ZooChi.gf (./example-code/Zoo/)

Und auch hier können wir durch Einsetzen der Konstanten in die Kombinationsregel \inlst$Pred$ erkennen, was linearisiert wird:

Pred vstr    fres    beer  = vstr    ++ fres    ++ beer ;

Pred VStrauß Fressen Beere = VStrauß ++ Fressen ++ Beere ;

Pred VStrauß Fressen Beere = "鸵鸟" ++ "吃" ++ "浆果" ;

Pred VStrauß Fressen Beere = "鸵鸟 吃 浆果" ;

Wie schon angekündigt, verwenden wir also in der chinesischen konkreten Grammatik nun dieselben Konstanten mit derselben Regel (\inlst$Pred$), wie auch schon in der deutschen Grammatik, nämlich \inlst$Pred VStrauß Fressen Beere$. Diese Regel-Anwendung (und mithin diese Baumstruktur) kann also als Schnittstelle für die Übersetzung zwischen verschiedenen Sprachen dienen: Wir wissen, wenn wir das semantische Modell \inlst$Pred VStrauß Fressen Beere$ sowohl in der chinesischen als auch in der deutschen konkreten Grammatik implementiert haben, dass uns eine linearisierbare Zeichenketten für beide Sprachen zur Verfügung steht (siehe Auflistung lst:eq-reg). Das semantische Modell stellt also ein zwischen-sprachliches Konstrukt (Interlingua) dar, dass für Übersetzung genutzt werden kann. Folglich ist auch ein Ausbau der übersetzbaren Sprachen leichthin möglich, indem neue konkrete Grammatiken der übersetzbaren Sprachen an die vordefinierte Interlingua »andocken«, indem sie die Regeln des semantischen Modell mit ihren sprach-spezifischen Zeichenketten implementieren.

#+CAPTION[Äquivalenz über Regeln]: Identische Regeln in ZooChi und ZooGer garantieren Übersetzbarkeit

"der Strauß frißt Beeren" = Pred VStrauß Fressen Beere = "鸵鸟 吃 浆果"

Wir werden im GF-Expositions-Kapitel genau beleuchten, wie das semantische Modell in abstrakten Grammatiken definiert und in konkreten Grammatiken implementiert wird (nur letzteres haben die Ausschnitte jetzt gezeigt). Aber schon hier sollte offensichtlich sein, wie ein semantisches Modell (abstrakte Grammatik) als beständiger Dreh- und Angelpunkt fungiert.

Einfache Flexibilität: Permutation, Reduplikation

Bietet uns das semantischen Modells nun eine Bestimmtheit der ausdrückbaren Bedeutungen, so erlauben uns die konkreten Grammatiken in ihrem Zuschnitt auf eine bestimmte Zielsprache Flexibilität. Die bisherigen Beispiele waren nur in dem Sinne flexibel, als sie zeigten, dass die Zeichenketten der Linearisierungs-Regeln für eine bestimmte Sprache konfigurierbar sind: In der deutschen Grammatik nutzen wir \inlst$Fressen = “frißt”$; in der chinesischen \inlst$Fressen = “吃”$. Auch bot die identische Hauptsatzstruktur beider Sprachen keinerlei Anlass über eine Flexibilität nachzudenken, die über das bloße Vokabular hinausgehen: Beide Sprachen greifen auf die Satzgliedstellung Subjekt-Prädikat-Objekt (S-P-O) zurück. Ganz anders wäre es dagegen im Lateinischen, wo durchgängig die Stellung Subjekt-Objekt-Prädikat (S-O-P) herrscht. Eine einfache Grammatik für das Lateinische, die diesen Zusammenhang sicherstellt, zeigt folgende Auflistung: #+CAPTION[ZooLat]: Ausschnitt aus der konkreten Grammatik ZooLat.gf (./example-code/Zoo/)

Die Möglichkeit, Zeichenketten durch Kombinationsregeln unterschiedlich anzuordnen (Permutation), ist eine der grundlegenden Freiheiten, die GF auf Zeichenketten-Ebene offeriert. Weitere Möglichkeiten, die allein mit Zeichenketten operieren, sind Reduplikation und Suppression. Reduplikation bedeutet, dass man Argumente in der Definition der Regel mehrmals angegeben kann:

Pred vstr    fres    beer  = vstr ++ fres ++ fres ++ beer ;
Pred VStrauß Fressen Beere = "鸵鸟" ++ "吃" ++ "吃" ++ "浆果" ;
Pred VStrauß Fressen Beere = "鸵鸟 吃 吃 浆果" ;

\verb$”鸵鸟 吃 吃 浆果”$, auf Deutsch etwa: »Der Strauß isst ein paar Beeren.« (Reduplikation des Verbs hat eine limitierende Wirkung auf die gesamte Handlung.[fn:: Ein besseres Beispiel für Verb-Reduplikation wäre: \xpinyin*{请你尝}\xpinyin{尝}{chang}\xpinyin*{那}\xpinyin{个}{ge}\xpinyin*{菜}! (Bitte koste doch mal jenes Gericht!), siehe \cite[29]{li_mandarin_1989}. Andererseits, so \cite[158]{xiao_aspect_2004}, steigere die Limitierung auf eine kürzere Zeitspanne auch die Intensität der Handlung. Die Verbhandlung wirke so am dynamischsten: 她红了脸 (She blushed) vs. 她红红脸 (She blushed up).])

Die Suppression beschreibt hingegen die Unterdrückung bzw. Nicht-Anwendung von Argumenten bei der Linearisierung, was für Anapher-Resolution genutzt werden kann.[fn::Vgl. \cite[47,141-143]{ranta_grammatical_2011}. In \cite[10]{dybjer_machine_2012} wird ein Beispiel dazu durchgesprochen.]

Festhalten grammatischer Strukturen und Regeln

Eine zusätzlich Ebene der Flexibilität wird durch Datensätze und Tabellen (records respektive tables, siehe rectables) geschaffen. Sie dienen dazu morphologische und syntaktische Informationen einer Sprache festzuhalten. Beispielsweise können wir alle grammatischen Kasus und das grammatische Genus (i. e. alle morphologischen Eigenschaften) des deutschen Lexems »(Vogel-)Strauß« in folgender Datenstruktur aus Datensätzen und Tabellen hinterlegen:

#+CAPTION[Morphologischer Datensatz]: Datensätze und Tabellen für die Morphologie des Lexems »Strauß«

Aus der Konstante strauß_N können dann einzelne Elemente mittels der Operatoren Datensatz-Projektion (.) und Tabellenselektion (!) weiterverwendet werden. Zum Beispiel verwendet \verb$”strauß_N . s ! Pl ! Dat”$ den dativischen Plural, also »Straußen«.

Und natürlich können wir auch mittels Hilfsfunktionen die Erstellung solcher Datenstrukturen automatisieren. So lässt sich im folgenden mit den Hilfs-Funktionen reg1N (reguläres Nomen mittels einer Zeichenkette) und casetable die schon angesprochene Datenstruktur strauß_N herstellen.

#+CAPTION[Operations-Definitionen]: Zwei Behelfs-Operationen zur Erstellung morphologischer Eigenschaften

Die beiden Funktionen gehören zu den sog. Operations-Definitionen, die zwar einen eigenen Bereich innerhalb der konkreten Grammatiken bestreiten (also getrennt von den Linearisierungs-Regeln zu betrachten sind), deren grundlegende Funktionsweise sich aber nicht von den Linearisierungs-Regeln unterscheidet. (Siehe Exposition/oper)

Das heißt, dass wir in Zeile 1 auf der LHS zunächst den Namen der Funktion, reg1N, dann zwei Argument-Variablen, strauß sowie g, haben, bevor sich die Funktionsdefinition auf der RHS anschließt. Innerhalb von reg1N wird dann in den Zeilen 6 und 7 die zweite Hilfsfunktion casetable mit jeweils vier Argumenten aufgerufen. Wird also die Funktion reg1N mit zwei Argumenten, etwa \inlst$”Strauß”$ und Masc, aufgerufen, so erhalten wir die Datenstruktur strauß_N, wie schon in Auflistung strauss_N gezeigt.

Mit reg1N könnten wir dann die Regel VStrauß auch so schreiben:

VStrauß = "der" ++ (reg1N "Strauß" Masc).s ! Sg ! Nom ;

Was letztlich wieder identisch ist zu:

    VStrauß = "der" ++ "Strauß" ;
-- Evaluation von (++)
    VStrauß = "der Strauß" ;

Man bemerke: Die Kombination von Funktionen, wie auch schon die Linearisierungs-Regeln kombinierbar waren

• die Auslagerung von Berechnungsvorgängen in Funktionen ist eine Abstraktion: sie lässt uns von konkreten Berechnungen, die die Funktion erbringt, absehen
• die Funktion reg1N ist linguistisch gesehen ein morphologisches Paradigma, das besagt, für eine Vielzahl der Nomen deutscher Sprache genügt es, eine Ausgangsform (das Lemma »Strauß«) und das Genus des Nomens an die Funktion reg1N zu übergeben, um als Resultat alle morphologischen Eigenschaften des Nomens (die Deklinations-Tabelle plus die morphologische Eigenschaft maskulin) zu erhalten.
• Paradigmen, sei es zur Syntax oder Morphologie, zu finden und festzuschreiben, ist im Kontext von Programmierung und System-Architektur sinnvoll, um das wiederholte Anfertigen annähernd gleicher Datenstrukturen zu vermeiden. Die Abstraktion durch Paradigmen bedeutet etwa für die GF-RGL, dass Lexikon-Einträge indirekt über Funktionen wie reg1N und nicht direkt über eine Datenstruktur (wie in Abb. strauss_N) erstellt werden.

Diversifikation von Paradigmen: »smarte Paradigmen«

• reg1N sehr simpel, indem diese Funktion nur einen Fall behandelt. Eine Fallunterscheidung der Funktionsweise von reg1N wird ermöglicht über den Musterabgleich in Zeichenketten (und anderen Parametern) mittels regulärer Ausdrücke:

#+Caption[Smart-Paradigma]: Smart-Paradigma für Paradigmen, die mit einer Zeichenkette sowie Genus-Merkmal gebildet werden können

reg1N nomen g =
  case <nomen,g> of {

    <_ + ("el"|"er"|"en") , Masc | Neutr> => [...] ; -- tue X

    <_ + "e" , Masc> => [...] ; -- tue Y

    <_       , Masc> => [...] ; -- der strauß_N-Fall

    <_       , _   > => [...] ; -- catch-all: tue Z

  } ;

In Abbildung smart-paradigma benutzen wir das Sprachkonstrukt \inlst$case … of$ zum Musterabgleich, der sich auf beide Argumente, die reg1N nimmt, bezieht. Dafür werden nacheinander drei Muster geprüft,

1. in Zeile 4, wenn die Zeichenketten-Variable nomen auf \inlst$”el”$, \inlst$”er”$ oder \inlst$”en”$ endet und der Genus-Parameter g maskulin oder neutral ist, dann tue X;
2. in Zeile 6, wenn nomen auf \inlst$”e”$ endet und g maskulin ist, dann tue Y;
3. in Zeile 8, wenn nomen beliebig ist und g maskulin, dann erstelle die bekannte strauß_N-Datenstruktur;
4. in Zeile 10, wenn nomen und g beide beliebigen Inhaltes sind, dann tue Z.

Man beachte die sequentielle Anordnung: Wäre der Abgleich für Z zuoberst aufgeführt, dann könnten die restlichen Fälle nie abgeglichen werden, weil Z immer zuerst bejaht würde.[fn::Die sequentielle Natur des Abgleichs ermöglicht auch die Implementierung von Wahrscheinlichkeiten, vgl. \cite[646]{detrez_smart_2012}: »[\ldots] a smart paradigm uses heuristics (informed guessing) if string matching doesn’t decide the matter; the guess is informed by statistics of the distributions of different inflection classes.«]

Damit wäre generell die Möglichkeit gegeben, innerhalb eines Paradigmas mehrere Möglichkeiten der Behandlung zuzulassen. Weitere Fälle, die nicht in das bisherige reg1N-Paradigma passen, wie etwa die Umlaut-Modifikation von Singular zu Plural (Kuh, Kühe), müssen dagegen mit einem eigenen Paradigma erfasst werden. Der Aufruf einer eigenen paradigmatischen Funktion für diesen Fall wäre dann \inlst$reg2N$ \inlst$”Kuh”$ \inlst$”Kühe”$ Fem und das Resultat wiederum eine Deklinations-Datenstruktur samt Genus, wobei sich innerhalb dieses Paradigmas, das mit zwei Zeichenketten-Argumenten rechnet, abermals Fälle ergeben, die via Musterabgleich nunmehr als Smart-Paradigma (reg2N) gesammelt werden.

Alsdann wäre unlängst aus Sicht der Linguistin das Wichtigste getan: Die Formulierbarkeit paradigmatischer Flexions-Regeln wird durch Funktionen erfüllt und auch die Gruppierung dieser Regeln in Smart-Paradigmen – über die Anzahl der Argument-Zeichenketten – ist nicht unnütz, weil sie uns die Auswahl eines konkreten Paradigmas abnimmt. Die paradigmatische Komplexität einer Sprache wird also durch Smart-Paradigmen gesenkt.

Universal-Sprach-API der Resource Grammar Library (RGL)

Der Ausgangspunkt dieses Kapitels war es, eine multilinguale Applikationsgrammatik zu erstellen. Da der Ersteller dieser Grammatik nicht in allen Sprachen, welche die Grammatik bieten bzw. mit denen sie später erweitert werden soll, bewandert sein kann, wäre es wünschenswert einen möglichst sprach-neutralen Zugang zu Morphologie und Syntax der jeweiligen Sprache zu haben. Sprach-neutral würde bedeuten, dass etwa für die Bildung eines Nomens genau eine Funktion zuständig, die in allen Sprachen implementiert ist. Das ist aber mit den Paradigmen, die wir bisher beispielhaft für das Deutsche entwickelt haben, unmöglich, denn die Benennung der Smart-Paradigmen, wie

• reg1N für u. a. »Strauß« sowie
• reg2N für u. a. »Kuh«, »Kühe«,

sind allzu sprach-spezifisch, als dass sie für beliebige Sprachen gelten könnten. Beispielsweise benötigt das Nomen-Paradigma in der chinesischen Ressourcen-Bibliothek nur eine einzige Funktion, da Flexion hier generell nicht vorhanden ist, wobei der Bibliotheks-Autor sich dazu entschieden hat, sie regNoun nennen, was natürlich keinem der Funktionsnamen in der deutschen Paradigmatik entspricht.

Man könnte nun versucht sein, Konventionen für die Benennung zu schaffen, an die sich jeder Bibliotheks-Autor halten muss, aber das würde ständige Koordinationsarbeit unter den Autoren mit dennoch sehr zweifelhafter Synchronitätsgarantie bedeuten. Außerdem sollte jedem Autor eine gewisse Freiheit bei der Benennung paradigmatischer Funktionen zugestanden werden.

Da eine direkte Angleichung der Namen nicht fruchtet, scheint es angezeigt, eine weitere Abstraktionsebene für die Vereinheitlichung zu schaffen. Wie auch schon bei den Smart-Paradigmata, die eine Art Sammelbecken für primitive Paradigmen boten, können wir verschiedene Smart-Paradigmata (oder auch primitive, wie beim Chinesischen) in einer Funktion sammeln, wodurch die Benennungsunterschiede versteckt, also abstrahiert, werden. Vereinheitlichten wir nun etwa die Benennung aller Nomen-Paradigmen mit einer übergeordneten Sammel-Funktion namens mkN (makeNomen), dann könnten wir folgendes schreiben:

#+Caption[mkN-API-Beispiel]: Namens-Vereinheitlichung von Paradigmen auf API-Ebene

-- zwei deutsche Smart-Paradigmen:
mkN = reg1N ;
mkN = reg2N ;

-- ein chinesisches (primitives) Paradigma: 
mkN = regNoun ;

Womit offensichtlich die angestrebte Vereinheitlichung erreicht wäre – etwas Geduld bitte für die seltsame Doppelbelegung von mkN im deutschen Teil – d. h. wenn der Autor einer spezifischen Sprach-Bibliothek die mkN-Abstraktion implementiert hat, dann hat ein Nutzer dieser Bibliothek via mkN eine simple Handhabe, Nomen zu bilden, weil er die genauen Paradigmen der Sprache nicht kennen muss. Der Autor hingegen, kann nicht nur die Paradigmen relativ frei benennen, sondern etwa auch zusätzliche (Smart-)Paradigmen für Nomen anfertigen – gesetzt dem Fall natürlich diese werden auch wieder mit mkN verknüpft.

De facto entkoppeln wir also die Nutzung der Sprach-Bibliothek von deren Entwicklung, was software-architektonisch ein gängiges Verfahren darstellt und dessen Ergebnis Elemente (wie mkN) einer Abstraktionsschicht sind. Diese Abstraktionsschicht wird als Application Programming Interface (API), also als eine Benutzer-Schnittstelle zum Programmieren von Applikationen, bezeichnet, wobei im Falle von GF die Applikation in erster Linie eine Applikationsgrammatik ist.

Nun ist da immer noch das Problem der Mehrfachbelegung von mkN mit zwei deutschen Smart-Paradigmen, was auch, da viele Sprachen morphologischen Reichtum nicht vermissen lassen, der Regelfall ist. Die Frage ist nun also, wie wir – wenn mkN sowohl auf reg1N als auch reg2N verweisen – den Verweis disambiguieren können, und die Antwort darauf liegt in den Argumenten der paradigmatischen Funktionen. Nämlich besteht ganz klar ein Unterschied darin, dass reg1N eine Zeichenkette und reg2N zwei als Argumente (neben dem ebenfalls obligatorischen Genus-Argument) benötigt, um evaluiert zu werden, und in GF können wir diesen Sachverhalt auf Typen-Ebene konkretisieren:

#+Caption[Typ-Deklarationen]: Typen-Deklarationen zu den dt. Paradigmen

reg1N : Str -> Gender -> N ; -- Typen-Deklaration zur Funktion reg1N
reg1N   strauß   g    = [...]

reg2N : Str -> Str -> Gender -> N ;
reg2N   kuh    kühe   g      = [...]

Abbildung type-regxn zeigt zusätzlich zu den schon verwendeten Funktions-Definitionen (in Zeile 2 und 5) diesmal auch die Typen-Deklarationen (in 1 und 4).[fn:: Typen einer Funktion werden also deklariert während Funktionen mit den konkreten Berechnungen, die auf der RHS geschehen, definiert werden.] Eingeleitet mit einem Doppelpunkt nach dem Funktions-Namen, auf die sich die Deklaration beziehen, geben die einzelnen Typ-Bezeichnungen (getrennt durch einen Pfeil nach rechts) an, welche Werte eine Argument-Variable annehmen darf. Demzufolge muss das erste Argument von reg1N vom Typ einer Zeichenkette (Str, String) und das zweite eines vom Typ Genus (Gender) sein, damit die Funktion einen Rückgabewert vom Typ Nomen (N) liefern kann. Analog dazu braucht reg2N ein Zeichenketten-Argument mehr. Man beachte nun, dass, wenn wir im reg1N-Falle \inlst$mkN = reg1N$ definieren, die Typen-Deklaration von reg1N sich auf mkN überträgt; natürlich analog auch für reg2N:

mkN : Str -> Gender -> N ;
mkN = reg1N ;

mkN : Str -> Str -> Gender -> N ;
mkN = reg2N ;

Was bedeutet, dass ein formales Unterscheidungskriterium für die Disambiguierung innerhalb der Sammel-Funktion mkN unlängst vorhanden ist: die Typen-Deklaration. Aber auch wenn nun die paradigmatischen Funktionen in mkN auf Typen-Ebene unterschieden werden können, so ist die doppelte Nutzung der Funktions-Bezeichnung dennoch für den Compiler problematisch. Benötigt wird ein Sprach-Konstrukt, was auf die Mehrfachnutzung von Funktions-Bezeichnungen hinweist. Da hier eine Funktion mehr Arbeit auf sich nimmt als ihr eigentlich gebührt, sprechen wir vom Überladen dieser, was sich in GF als overload-Block entpuppt:

mkN = overload {
  mkN : Str -> Gender -> N = reg1N ;
  mkN : Str -> Str -> Gender -> N = reg2N ;
  } ;

• Beispiel-Code von Zoo mit Ressource! (syntaktische Funktion mkCl!)
• TODO: GF-Shell vor/in Motivation
• Bogen nun gespannt von Linearisierungs-Regeln über normale und smarte Paradigmen zu den überladenen API-Funktionen; Arbeitsteilung: Programmierer schafft semantisches Modell, was sich in möglichen Linearisierungs-Regeln ausdrückt; Linguist/Grammatiker erstellt Ressourcen-Grammatiken (weitere Differenzierung zwischen Lexikograph und Sprach-Experte hier möglich)
• wo war aufgelistet, die Ratio zwischen GF-Code und expandierten Regeln?
• [fn::Die relativ ähnlichen Benennungen von vielen Paradigmen scheint noch Zeuge davon zu sein, dass eine Vereinheitlichung der Benennungen versucht wurde. Siehe \cite[22]{ranta_molto_2012}.]
• Weitere Elemente, mkV, mkA -> Synopse zeigen?

-> pivot lang -> indirekte Übersetzung (Interlingua)\cite{carstensen_computerlinguistik_2004}: REFTODO: Seite! Gibt eine Darstellung von Interlingua bei MÜ und verweist auch auf Maegaard für das Thema Sackgasse bei Interlingua MÜ:

• TODO:\cite{maegaard_mlim:_2001}:»Ideally, systems will employ statistical techniques to augment linguistic insights, allowing the system builder, a computational linguist, to specify the knowledge in the form most convenient to him or her, and have the system perform the tedious work of data collection, generalization, and rule creation. Such collaboration will capitalize on the (complementary) strengths of linguist and computer, and result in much more rapid construction of MT systems for new languages, with greater coverage and higher quality. Still, how exactly to achieve this optimal collaboration is far from clear. Chapter 6 discusses this tradeoff in more detail.« Fragen die GF beantworten kann? Natürlich werden Regeln nicht von GF erzeugt und statistische Methoden werden auch nicht standardmaäßig beim Parsen benutzt. Der Abschnitt lässt sich also so nicht benutzen, sondern vielmehr geht aus auf die Stärken bei GF was Arbeitsteilung/Modularisierung einzugehen. Robusteres Parsing ein zweites Thema zu den Stärken.

Exposition

Überblick

Der Ablauf des GF-Expositions-Kapitels gliedert sich in die aufeinander aufbauende Darstellung folgender Punkte:

Module und Regeln für Grammatiken

Grundlegende Terminologie in Modulen, die zusammen eine multilinguale Grammatik bilden (abstrakte und konkrete Grammatiken)

Interaktion mit den Grammatiken

Demonstration der Grammatik (Übersetzung etc.) in der GF-Shell

Erläuterung des Datenmodell

Mit Hilfe des Gelernten und Beobachteten das Datenmodell erläutern[fn:: Mit der Erläuterung des Datenmodell wird gleichzeitig eine praxisnahe Einführung in die Verwendung von Typen in GF sowie die curryfizierte Funktionsanwendung (curried function application) gegeben. Dies hat nicht nur den für uns hier praktischen Vorteil, dass Fehlermeldungen beim Kompilieren der Grammatiken eingeordnet werden können, sondern bietet auch generell eine Grundlage für das Verständnis Funktionaler Programmierung (FP). REFTODO: Sektion über FP-Geschichte?!]

Module und Regeln

Die folgenden 3 GF-Module (Zero.gf, ZeroGer.gf, ZeroChi.gf in Auflistung \ref{mj1}), deren Inhalt nur der Übersicht halber nebeneinander abgedruckt wird, ermöglichen eine Übersetzung der in ihnen beschriebenen semantischen Einheiten vom Chinesischen ins Deutsche und umgekehrt:

#+CAPTION[Hallo GF]: 3 Module einer multilingualen Grammatik (./example-code/Zero/)

--Zero.gf:                   --ZeroGer.gf:                   --ZeroChi.gf:
abstract Zero = {            concrete ZeroGer of Zero = {    concrete ZeroChi of Zero = { 
  cat                          lincat                          lincat                      
    S;   -- sentence             S, NP, VP, V2 = Str;             S, NP, VP, V2 = Str;
    NP;  -- noun phrase
    VP;  -- verb phrase
    V2;  -- two place verb
  fun                          lin                             lin
    Pred : NP -> VP -> S;        Pred np vp = np ++ vp;           Pred np vp = np ++ vp;
    Compl : V2 -> NP -> VP;      Compl v2 np = v2 ++ np;          Compl v2 np = v2 ++ np;
    John, Mary : NP;             John = "Johann";                 John = "约翰";
    Love : V2;                   Mary = "Marie";                  Mary = "玛丽";
                                 Love = "liebt";                  Love = "爱";
}                            }                               }

Jedes der Module besteht zunächst aus einer Kopfzeile (dem Header, siehe Zeile 2 von \ref{mj1}), der angibt, ob es sich um eine abstrakte oder konkrete Grammatik handelt, gefolgt vom Namen des Moduls. Der Modulname entspricht dem Namen der Datei, in der sich das Modul befindet, ohne Dateiendung. So befindet sich etwa das abstrakte Modul Zero in der Datei Zero.gf. Einzeilige Kommentare können mit --, mehrzeilige mit {- und -} in den Quellcode geschrieben werden.[fn:: Die Zero-Grammatik ist eine Abwandlung der Beispiele in \cite{ranta_gf-lrec-2010.pdf_2010} sowie \cite{_grammatical_2014}.]

Nach dem Modul-Header wird der Modul-Hauptteil (der Body) mit »= {« eingeleitet und mit »}« abgeschlossen, wobei wir es innerhalb des Hauptteils mit verschiedenen Urteilen oder Regeln (judgements or rules) zu tun haben.[fn:: \cite[45]{ranta_grammatical_2011}] Abstrakte Module, wie Zero, benutzen hauptsächlich zwei Arten von Regeln, die mit folgenden Schlüsselwörtern eingeleitet werden:

$∗$ cat

Kategorien-Deklarationen, die die Kategorien (Typen von Bäumen) beschreiben

$∗$ fun

Funktions-Typen-Deklarationen, die die verschiedenen Kategorien miteinander in Beziehung setzen

Konkrete Module, wie ZeroGer und ZeroChi, haben im Header nach dem Schlüsselwort conrete ebenso ihren Namen, müssen aber auch noch anführen, auf welche abstrakte Grammatik sie sich beziehen. In unserem Fall zeigt of Zero an, dass sie sich auf das Modul in der Datei Zero.gf beziehen. Daraufhin beginnt auch hier der Modul-Body, in dem wir auch wieder zwei Arten von Regeln vorfinden:

$∗$ lincat

Linearisierungs-Typ-Definitionen, die den Typ der Ausgabe-Objekte des \inlst$linearize$-Kommandos definieren

$∗$ lin

Linearisierungs-Regeln für Kategorien

Man beachte die Korrespondenz zwischen den fun-Regeln im abstrakten Modul und den verschiedenen lin-Regeln der konkreten Grammatiken: Zum Beispiel wird mit dem Ausdruck Compl in der abstrakten Grammatik eine Funktion mit dazugehöriger Typen-Deklaration hinter dem Doppelpunkt eingeführt. Die Typen-Deklaration beschreibt, welchen Typ die Objekte haben dürfen, die die Funktion Compl als Argumente nimmt.

abstract Zero = {             concrete Zero___ of Zero = {
[...]
    Compl : V2 -> NP -> VP;      Compl v2 np = v2 ++ np; -- ident. Definition in
[...]                                                    -- ZeroChi und ZeroGer
}                             }

Im Beispiel von Compl etwa bedeutet die Typen-Deklaration \inlst$V2 -> NP -> VP;$, dass zwei Argumente, zunächst vom Typ V2 und dann vom Typ NP, benötigt werden, um ein Objekt vom Typ VP zu erzeugen. Wir sagen, die Argument-Typen (argument type) der Funktion Compl sind V2 und NP und der Wert-Typ (value type) derselben ist VP. Der Sachverhalt, wieviele Argumente eine Funktion nimmt, wird mathematisch auch mit den Begriff der Stelligkeit bzw. Arität beschrieben; Compl hat daher eine Arität von zwei.

Welche konkreten Objekte dann mit dieser abstrakten Typen-Deklaration verbunden werden, ist ersichtlich aus den Linearisierungs-Regeln der konkreten Grammatiken. Die beiden konkreten Grammatiken ZeroChi und ZeroGer haben in unserem Beispiel dieselbe Definition von Compl, nämlich \inlst$Compl v2 np = v2 ++ np;$. Die Komponenten dieser Definition sind:

Compl

der Name der Funktion für die Funktions-Definition, der mit dem Namen der Funktions-Typ-Deklaration übereinstimmen muss

v2 und np

die Argumente der Funktions-Definition, die prinzipiell beliebig gewählt werden dürfen, die aber hier namentlich darauf hinweisen, dass das Objekt, das sie referenzieren, vom Typ V2 bzw. NP ist

=

das Gleichheitszeichen leitet den Funktionskörper (funtion body) ein

v2 ++ np

hier werden die beiden Argumente der Compl-Funktion mittels ++-Operator verkettet (String-Konketenation)

;

wie jede Regel bzw. Urteil wird der Funktionskörper mit einem Simikolon beendet

Interaktion in der GF-Shell

Die GF-Shell bietet über verschiedene Kommandos einen interaktiven Zugang zu den Grammatiken.[fn:: Für eine ausführlichere Einführung in die Arbeit mit der Shell, siehe http://www.grammaticalframework.org/doc/tutorial/gf-tutorial.html (etwas in die Jahre gekommen, aber die grundlegenden Ausführungen zur Shell und viele weitere Dinge sind noch aktuell) sowie im Handbuch zu \cite[31]{ranta_grammatical_2011}.] Um die Grammatiken der letzten Sektion in der Shell zu testen, müssen wir zunächst die Grammatik-Module laden, was am einfachsten geschieht, wenn wir zunächst in das Verzeichnis navigieren, wo sich dieselben befinden. Im jeweiligen Kommandozeilen-Interpreter[fn:: Unter Windows sollten standardmäßig zwei Shells zur Verfügung stehen: cmd.exe und Powershell; (Mac) OS X: iTerm] des Betriebssystems sollte nach der Installation von GF ein gf-Programm verfügbar sein, sodass wir die GF-Shell damit starten können. Beim Aufruf kann man entweder gleich die betreffenden Grammatik-Modul-Dateien angeben (\inlst$>gf ZeroChi.gf ZeroGer.gf$), sodass man mit den geladenen Grammatiken arbeiten kann:

Oder man startet die GF-Shell einfach mit gf (also ohne jedwede Datei-Argumente) und importiert dann mittels des import-Kommandos von der GF-Shell aus die Modul-Dateien:

Übersetzung: parse/linearize

<<parse-lin>> In jedem Fall sollte es dann möglich sein, folgende Kommando-Kombination auszuführen:

#+CAPTION[Übersetzungskommandos in der GF-Shell]: GF-Shell: Standard-Übersetzungs-Kommandoabfolge: parse, »|« (Pipe), linearize

Languages: ZeroChi ZeroGer
Zero> parse -lang=ZeroChi "约翰 爱 玛丽" | linearize -lang=ZeroGer
Johann liebt Marie

In Zeile 1 von Auflistung \ref{pl1} sehen wir die geladenen konkreten Grammatiken, die wir für eine Übersetzung heranziehen können hinter der Beschriftung »Languages«. Sie bilden also den Geltungsbereich (engl. scope) für die Arbeit in der Shell. Zeile 2 beginnt mit dem sogenannten Prompt, der sich aus dem Namen der geladenen abstrakten Grammatik (sofern geladen) sowie einer nach rechts ausgerichteten Spitzklammer zusammensetzt. Nach dem Prompt können wir unsere Eingaben tätigen. In der angesprochenen Auflistung ist die Eingabe eine Kombination von Kommandos, die eine Chinesisch-Deutsch-Übersetzung bewerkstelligt.

Im einzelnen werden dafür zwei Kommandos, parse und linearize, und ein Operator benötigt, der die Ausgabe des ersten Kommandos an das zweite weiterleitet. Der genaue Ablauf sieht folgendermaßen aus:

1. Eine chinesische Zeichenkette oder auch String (\inlst$”约翰 爱 玛丽”$) wird mittels parse -lang=ZeroChi eingelesen und verarbeitet.[fn:: Man beachte, dass ein String, der eingelesen werden soll, in Anführungszeichen eingeschlossen sein muss. Obligatorisch ist außerdem, die einzelnen Zeichenketten (Tokens) im String durch ein Leerzeichen zu trennen.]
2. Das Ergebnis der Verarbeitung wird durch den sog. Pipe-Operator, |, weitergeleitet \ldots{}
3. \ldots{} an linearize, das eine deutsche Übersetzung mittels -lang=ZeroGer in Zeile 3 generiert.

Aus der Beobachtung dieses Ablaufs ergeben sich mindestens zwei Fragen:

1. Was genau wird von dem Pipe-Operator weitergeleitet?
2. Wie genau steht dieser Ablauf im Verhältnis zu den von uns oben angeführten drei Grammatiken? (Auflistung \ref{mj1})

Frage 1 können wir oberflächlich in der Shell beantworten, indem wir den Pipe-Operator und linearize weglassen.

#+CAPTION[AST: Klammernotation]: AST in Klammernotation

Zero> parse -lang=ZeroChi "约翰 爱 玛丽"
Pred John (Compl Love Mary)

Um diese Ausgabe zu interpretieren und auch die zweite Frage zu beantworten, müssen wir uns eingehend mit Bäumen als Datenstrukturen auseinandersetzen.

Datenmodellierung und Prüfung

Abstrakter Syntax Baum/Tree (AST)

<<astcat-intro>> Was parse in Auflistung \ref{mj-hello-ast} zurück liefert, sind die semantischen Einheiten unseres geparsten Satzes als sog. Abstrakter Syntax Baum (Abstract Syntax Tree, kurz AST) in Klammernotation. Diese Notation lässt nicht intuitiv vermuten, dass es sich bei \inlst$Pred John (Compl Love Mary)$ um eine Art Baum handelt. (Obwohl die Klammern um Compl Love Mary wie in einer mathematischen Gleichung einen Hinweis darauf geben, dass etwas, nämlich ein geklammerter Ausdruck, zuerst berechnet werden muss.) Um uns nun diesen Vergleich mit einer Baum-Struktur zu verdeutlichen, können wir das GF Kommando visualize_tree in Verbindung mit dem Visualisierungs-Werkzeug »Graphviz«[fn::http://www.graphviz.com] einsetzen:

Zero> parse -lang=ZeroChi "约翰 爱 玛丽" | visualize_tree -view="firefox"

Damit sollte sich ein Programm unserer Wahl (hier der Firefox-Browser) mit der PNG-Bilddatei öffnen, das uns einen auf den Kopf gestellten Baum zeigt:

#+CAPTION[vt-1]: visualize\_tree produziert Graphen-Darstellung eines AST (»Abstact Syntax Tree«)

Nun sollte ersichtlich sein, was gemeint ist, wenn wir dem Ausdruck \inlst$Pred John (Compl Love Mary)$ eine Baumstruktur zusprechen: Die Wurzel eines Baumes ist Ausgangspunkt für verschiedene Äste, die zu unterschiedlichen Blättern führen. Im obigen Fall ist die Wurzel nun Pred von der ausgehend Äste zum Subjekt, John, und zum Prädikat (Compl \ldots{}) wachsen, wobei sich Compl wiederum verzweigt in Love und Mary.

Vergleichen wir nun diesen Graphen mit unserem abstrakten Syntaxmodul (Zero.gf), so zeigt sich eine Übereinstimmung zwischen den geparsten semantischen Einheiten des AST und den Namen der Funktions-Deklarationen im fun-Block:

abstract Zero = {
  cat                       -- Kategorien
    S; NP; VP; V2;
  fun                       -- Beginn des fun-Blocks
    Pred : NP -> VP -> S;
    Compl : V2 -> NP -> VP;
    John, Mary : NP;
    Love : V2;
}

Die jeweils durch ein Semikolon getrennten Funktionen im fun-Blocks geben an, wie die verschiedenen Kategorien des cat-Blocks produziert werden. Dies geschieht über sog. Typen-Deklarationen hinter dem Doppelpunkt. \inlst$Pred : NP -> VP -> S;$ bedeutet etwa, dass eine Funktion namens Pred zwei Argumente nimmt, zunächst eines vom Typ NP (Nominalphrase) und dann eines vom Typ VP (Verbphrase), um schließlich ein Objekt vom Typ S (Sentence) zu produzieren. Zur Erinnerung ist diese erste Funktion oder Regel in Abbildung \ref{jlm-eval-graph} rechteckig umrandet.[fn:: TODO: Funktion oder Regel: logisch/semantisch?!]

#+CAPTION[eval-1]: Evaluations-Reihenfolge

Abbildung \ref{jlm-eval-graph} macht aber auch klar, dass das zweite Argument von Pred (vom Typ VP) sich nun wiederum aus zwei Komponenten zusammensetzt, was im Bild trapezförmig markiert ist und durch die Regel \inlst$Compl : V2 -> NP -> VP;$ in der abstrakten Grammatik beschrieben wird. Damit können wir jetzt auch die Parallele zur Klammernotation ziehen und sehen, dass mit ihr wirklich sehr kompakt der gesamte Baum beschrieben wird. So besagt \inlst$Pred John (Compl Love Mary)$, dass zunächst die Funktion Pred ihre erstes Argument John (vom Typ NP) zugespielt bekommt und dass dann aber – um das zweite Argument für Pred zu erhalten – vorrangig die Funktion Compl mit ihren eigenen Argumenten, Love und Mary, abgearbeitet oder evaluiert werden muss. Und gerade diese Vorrangigkeit oder Präzedenz der Evaluation wird mit den runden Klammern um Compl Love Mary beschrieben.

Prüfung des Datenmodells: Type Checking

Die Relation zwischen Funktions-Anwendung (engl. function application, das Befüllen oder Sättigen einer Funktion mit ihren Argumenten) im AST und den Kategorien/Typen können wir auch sehr gut in der Shell illustrieren: Wir füttern dafür das Kommando linearize (das ja einen AST nimmt, um einen String zu produzieren) mit unvollständigen Bäumen und beobachten was passiert.

Zero> linearize Pred John Compl
Couldn't match expected type VP
       against inferred type V2 -> NP -> VP
In the expression: Compl

Hier sehen wir nach dem Aufruf von linearize mit einem unvollständigen AST, wie die Linearisierung fehlschlägt und demzufolge kein String ausgegeben wird. Stattdessen teilt uns der Typ-Checker (engl. type checker) mit, dass der von uns bereitgestellte AST nicht den von uns in der Grammatik formulierten Erwartungen entspricht. Insbesondere bereitet der Ausdruck Compl Probleme, dessen Typ nicht mit jenem übereinstimmt, der als zweites Argument von Pred erwartet wird. Zur Erinnerung:

• \inlst$Pred : NP -> VP -> S;$
• \inlst$Compl : V2 -> NP -> VP;$

Pred erwartet ein Objekt vom Typ VP als zweites Argument; der Ausdruck Compl ist aber als Funktion noch vollkommen ungesättigt – ihm wurden also noch keine Argumente übergeben –, weswegen der Compiler den Typ vollkommen korrekt als \inlst$V2 -> NP -> VP$ ableitet oder inferiert (Zeile 3), was aber eben laut Typen-Definition nicht das zweite Argument von Pred sein kann. Daher der ausgegebene Typ-Fehler (type error) und der Abbruch des Kommandos. Beachten wir hingegen die Präzedenz-Klammerung (die runden Klammern sind also zwingend notwendig) und sättigen Compl mit allen notwendigen Ausdrücken (Funktionsargumenten), bekommen wir natürlich die Linearisierung unseres AST als Strings:

#+CAPTION[AST: Komplette Funktionsanwendung]: Kein Typ-Fehler: Funktion Compl vollständig mit Argumenten gesättigt

Zero> linearize Pred John (Compl Love Mary)
约翰 爱 玛丽
Johann liebt Marie

Damit hätten wir die Fälle gezeigt, in denen die Compl-Funktion, entweder keine Argumente erhält (Abb. \ref{compl-no-args}) oder alle (Abb. \ref{compl-all-args}). Der Vollständigkeit halber sei auch noch gezeigt, dass eine partielle Sättigung der Funktion (im Fall von Compl also mit nur einem Argument) möglich ist und wie dieser Fall vom Compiler interpretiert wird: #+caption[AST: Partielle Funktionsanwendung]: Typ-Fehler: Funktion Compl partiell gesättigt

Zero> linearize Pred John (Compl Love)
Couldn't match expected type VP
       against inferred type NP -> VP
In the expression: Compl Love

In Auflistung \ref{compl-part-args} wird die Funktion Compl auf ein Argument vom Typ V2 (Verb mit Platz für zwei Objekte: Subjekt und Objekt, Love) angewandt, was für den Typ-Inferenz-Mechanismus des Compilers laut Zeile 3 bedeutet, dass der Ausdruck Compl Love den Typ NP -> VP besitzt (\inlst$Compl Love : NP -> VP$). Auf diese spezielle Art der Funktionsanwendung, die partielle Applikation, sei an dieser Stelle schon hingewiesen, weil hiermit ein Merkmal funktionaler Programmiersprachen expliziert wird, das uns auch in GF als FP immer wieder begegnen wird: Jeder Ausdruck, den wir benutzen, um etwas zu berechnen oder um Daten zu modellieren, ist eine Funktion. Vielfach nehmen Funktionen zwar Argumente entgegen und verarbeiten diese, wie etwa Compl in der Zero-Grammatik:

Compl : V2 -> NP -> VP;      Compl v2 np = v2 ++ np;

Andere Ausdrücke, die keine Argumente nehmen, sind aber ebenso Funktionen, wie:

Love : V2;                   Love = "爱";
John : NP;                   John = "约翰";
Mary : NP;                   Mary = "玛丽";

Außerdem zeigt uns der Graph die Kategorien (cat)

Zero> linearize Pred John Compl
Couldn't match expected type VP
       against inferred type V2 -> NP -> VP

abstract Zero = {           concrete ZeroChi of Zero = {
  cat                         lincat
    S; NP; VP; V2;               S, NP, VP, V2 = Str;
  fun                         lin
    Pred : NP -> VP -> S;        Pred np vp = np ++ vp;
    Compl : V2 -> NP -> VP;      Compl v2 np = v2 ++ np;
    John, Mary : NP;             John = "约翰";
    Love : V2;                   Mary = "玛丽";
                                 Love = "爱";
}                           }

Zero> parse -lang=ZeroChi "约翰 爱 玛丽" | visualize_tree -view="firefox"
Pred John (Compl Love Mary)

#+CAPTION[Inkrementellse Parsing]: Inkrementelles Parsing und Vorschläge für das

Zero> linearize Pred 
Compl  John   Love   Mary   Pred -- Warum wird Compl vorgeschlagen?! -- das ist kein richtiges Inkrementelles Parsing; klar ist ja auch linearize... :P

Evaluation der chinesischen Ressourcen Grammatik

Daten und Arbeitsschritte

Ergebnisse der ersten Implementierung als Grundlage

Die Grundlage dieser Evaluation sind die Arbeiten Dr. Chens an der chinesischen Ressourcen-Grammatik aus dem Jahre 2012 und innerhalb dieser Arbeiten insbesondere ein Dokument, dass auch ihm zur Evaluation seiner Implementierung diente.[fn:: \cite{chen_peng_implementation_2013}. Zuvor waren zudem beteiligt: 乔海燕博士 （广州）， Prof. Aarne Ranta (Göteborg) sowie 卓琳其其格, cf. \cite{ranta_gf_2012}. Das Evaluationsdokument von 陈鹏 ist auffindbar bei \cite{chen_peng_evaluationsdokument:_2012}.] Dieses Dokument besteht aus drei-zeiligen Einträgen, wie dem folgenden:

mkUtt (mkVP beg_V2V he_NP (mkVP sleep_V))
to beg him to sleep
把他乞求睡 BAD 乞求他睡

Die erste Zeile zeigt den API-Funktions-Baum in Klammernotation, die zweite die aus diesem Baum resultierende englische Linearisierung und die dritte die ebenso resultierende chinesische – wobei die letztere Zeile zudem immer ein Kommentar bezüglich der Güte des Linearisierungsergebnisses (GOOD, BAD oder SOSO) sowie optional einen Korrekturvorschlag enthält.

Insgesamt handelt es sich um 450 Einträge, deren Bäume und die dazugehörige engl. Muster-Linearisierung (Zeile 2) aus der RGL-API-Synopse[fn::REFTODO: auf die Synopse sollte schon früher verwiesen werden! \cite{bringert_gf_2015}] entnommen sind. Die einfachsten davon bestehen nur aus einem Funktionsaufruf, der keine Argumente benötigt:

API-Funktion	engl. Linear.	chin. Linear.	Güte
therefore_PConj	therefore	因此	GOOD
always_AdV	always	一直	GOOD

Die kompliziertesten sind Bäume wie etwa dieser verschachtelte Fragesatz:

#+CAPTION[eng_chi2: Komplexer Eintrag]: Ein komplexer Satz mittels der RGL-API (API-Funktions-Baum zwecks Lesbarkeit formatiert)

mkUtt
 (mkQCl who_IP
        (mkClSlash she_NP know_VS
                   (mkSSlash
                    (mkTemp pastTense anteriorAnt)
                    negativePol
                    (mkClSlash we_NP
                               (mkVPSlash see_V2)))))
whom does she know that we hadn't seen
她知道我们不看了的是谁 SOSO 我们没看过的人里，她认识谁

Die Auswahl der 450 Bäume erhebt keinen Anspruch auf eine vollständige Darstellung der RGL, aber in jedem Fall lassen sich anhand dieser vielerlei syntaktische Strukturen auf (a) grammatische und (b) praktische Korrektheit (gängiges, gutes Chinesisch, das dem gewohnten Sprachgebrauch entspricht) hin prüfen. GOOD bescheinigt daher, dass sowohl (a) und (b) zutreffen; BAD, dass (a) nicht zutrifft; und SOSO, dass zwar (a) zutrifft, aber (b) nicht.[fn::\cite[33]{chen_peng_implementation_2013}.]

Unter Anwendung dieser Kriterien gelangte Chen zu dem Resultat, dass 338 der 450 Testfälle eine gute Linearisierung besitzen, womit auf die beiden Mangelkategorien insgesamt 112 – aufgeschlüsselt in 80 mal SOSO, 32 mal BAD – entfielen. Auch wenn nur 7% der Ergebnisse schlecht ausfielen, so wies Chen doch darauf hin, dass chinesische Charakteristika, wie Wortstellung, Funktionswörter und verschiedene Arten von komlexen und flexiblen Phrasenstrukturen, noch nicht gut gehandhabt werden.[fn::\Cite[34]{chen_peng_implementation_2013}.]

Auswertungsschritte und Datenaufbereitung

Anhand der von Chen aufgezeigten Problemfälle bewerte ich das grammatische Phänomen, das diesem Problemfall zu Grunde liegt, hinsichtlich der Implementierbarkeit in die chinesische Ressourcen Grammatik. Mit anderen Worten sind die Schritte, die bei der Evaluation durchlaufen werden, folgende:

• Ist das Problem durch GF und innerhalb der RGL lösbar?
  • wenn ja, dann: Lösung andeuten / Problematik untersuchen
  • wenn nein, dann: a. Limitationen von GF/RGL aufzeigen und/oder b. generelle Schwierigkeit/Unmöglichkeit besprechen (bezieht sich meist auf Kontextbasiertheit des Problems)

Bevor mit der Identifizierung von Problemen und Problemfeldern begonnen werden konnte, wurden Chens Daten bereinigt (z.B. gab es vereinzelte Duplikate) und Linearisierungen aktualisiert, die sich seit Ende 2012 verändert haben (siehe nächste Sektion how-to-test).

Zur besseren Handhabbarkeit der einzelnen Einträge sowie der verschiedenen Kategorien innerhalb dieser (Sortierbarkeit) wurde Chens Dokument in ein simples Tabellen-Dateiformat überführt.[fn:: Siehe, https://github.com/salamynder/mag15/blob/master/tests/eng_chi3.csv – die einzelnen Zellen einer Zeile sind durch jeweils ein Semikolon getrennt.] Aus dieser neuen Tabellen-Datei werden wiederum alle Auswertungs-Tabellen, die sich in diesem Dokument befinden, generiert.

Reproduktion der Linearisierungen

<<how-to-test>> Die chinesische Linearisierung der API-Funktionen lässt sich mittels des Quellcode-Moduls api/TryChi.gf (bzw. des kompilierten Moduls alltenses/TryChi.gfo) sowie des GF-Kommandos compute_concrete (cc) reproduzieren:

> i -retain alltenses/TryChi.gfo
> cc -one mkUtt (mkCN woman_N (mkRS (mkRCl which_RP beg_V2V he_NP (mkVP sleep_V))))
乞 求 他 睡 觉 的 女 人

Konstruktionen mit 是-（的）

Die 是-的-Konstruktion bietet eine Möglichkeit, bestimmte Satzglieder zu betonen, und erfüllt daher dieselbe Funktion wie Sperr- und Spaltsätze im Deutschen oder Englischen. 是 (shì) für sich genommen ist aber auch einfach das Vollverb »sein«, das für Klassifikation und Äquation zuständig ist. In den folgenden Daten wird genauer auf diese Parallelen und Funktionen eingegangen.

Diese Kategorie lässt sich zunächst grob unterteilen in Sätze, in denen der Einsatz von 是-（的）\hspace{0.2em} entweder unbedingt vonnöten oder aber auch sehr angeraten erscheint, und solche, in denen die Verwendung schlichtweg grammatisch falsch ist oder durch diese eine ungewöhnliche Betonung hervorgerufen wird.

Verwendung unnötig oder falsch [是-的-overuse]

Mit guter Bewertung:

<<mkqcl-better>> Man beachte, dass die ersten vier Zeilen der obigen Tabelle die angestrebte Korrektur schon zeitigen, d.h. 是-的 wird hier standardmäßig nicht mehr benutzt, was sich anhand der Chinesisch-Spalte zeigt, in der geteilt durch einen Pfeil (->) ein älteres und ein aktuelles Linearisierungsergebnis dokumentiert ist.[fn:: Diese positive Veränderung ist dokumentiert in Commit ba6bd33b vom 08.10.2013 und betrifft vor allem die Funktion QuestSlash aus \inlst$chinese/QuestionChi.gf$, die aufgerufen wird, wenn mkQCl als zweites Argument eines vom Typ ClSlash – also einem Satz (Clause), der ohne sein Objekt (NP) prädiziert wird – nimmt. REFTODO:Explanation:Slash!]

#+caption[whom-does-she-see]: »whom does she see« / 谁 richtig positioniert

mkUtt
 (mkQCl who_IP
        (mkClSlash she_NP
                   (mkVPSlash see_V2)))
$\Downarrow$ 她 看 谁

Zusätzlich zu Zeile 4: »whom does she beg me to see«

Auch wenn die eben erwähnte Regel gut für diesen Fall funktioniert, ist die Position des Interrogativpronomens 谁 (shéi, wer) falsch gewählt. Die Behebung dieses Fehlers ist höchstwahrscheinlich nicht problematisch, da hier nur die Kernfunktion QuestSlash (aufgerufen durch mkQCl: IP -> CLSlash -> QCl) angepasst werden muss.

#+caption[whom-does-she-beg-me-to-see]: »whom does she beg me to see« / 谁 falsch positioniert

mkUtt
 (mkQCl who_IP
        (mkClSlash she_NP
                   (mkVPSlash beg_V2V i_NP
                              (mkVPSlash see_V2))))
$\Downarrow$ 她 乞 求 谁 我 看

<<besser-kein-shi-de-weil-unbetont>> Die restlichen Zeilen (5–11) haben gemeinsam, dass hier noch kein Paradigma vorhanden ist, welches auf die Konstruktion mit 是-的 verzichten würde. 是 findet als Äquationalkopula in allen Fällen (mkCl : NP -> A/AP -> Cl) Anwendung, was vor allem in den Zeilen 5 bis 10 problematisch ist, da hier über die Äquation keine besondere Betonung realisiert wird. Zum Beispiel ist in der Aussage von Zeile 8 »she is old« grammatisch völlig unbetont, weswegen das chinesische Äquivalent eher heißen sollte \hspace{0.2em}「她很老」\hspace{0.2em} anstatt \hspace{0.2em}「她是老的」.[fn:: Für die Unterscheidung zwischen der Bildung des Ajektivprädikats mittels 很 oder 是， siehe \cite[126f.]{motsch_grundlagen_2010}: Die Klassifizierung mittels 是+Adjektiv+的 kann z.B. pejorativ gebraucht werden, wie etwa in 「姓王的， 不过是个教书的！」\hspace{0.3em} （Dieser Wang ist bloß Lehrer!） – wobei hier aber allein schon die Vokabel 个教书的 (jmd. der aus Büchern lehrt) gegenüber den respektsbezeugenden Anreden 教授 (jiàoshòu, Professor) und 老师 (lǎoshī, Lehrer) despektierlich ist.
Für die Unterscheidung der Nutzung von 是 oder nicht ist allgemein auch anzumerken, dass nicht-steigerbare Adjektive standardmäßig mit 是 prädiziert werden. Cf. \cite[69]{yip_chinese:_2004}.]

#+caption[Suche nach relevanten Funktionen]: Ob nun Fragesatz oder Aussagesatz: Viele der unterliegenden Kernfunktionen von mkCl und mkQCl sind gleich; angepasst werden müssen nur PredVP und QuestVP.

-- api/Constructors.gf
      mkCl : NP -> A -> NP -> Cl
        = \x,y,z -> PredVP  x (UseComp (CompAP (ComparA y z))) ;

      mkQCl : IP -> A -> NP -> QCl
        = \x,y,z -> QuestVP x (UseComp (CompAP (ComparA y z))) ;

Zu Zeile 11 (»it is here that she sleeps«):

Umgekehrt scheint aber eine grammatische Betonung von »here« in Zeile 4 [(a) »it is here that she sleeps«] durchaus vorzuliegen, denn die Satzaussage könnte auch einfacher mit (b) »she sleeps here« gebildet werden, wobei die Auslagerung eines zu betonenden Satzgliedes in einen vorangestellten unpersönlichen Satz (»it is \ldots{}«) gemeinhin als Spaltsatz bekannt ist.[fn::\cite[636]{busmann_lexikon_2008} Auch Kluftsatz (engl. cleft sentence) genannt. Chinesisch: 分裂句 (fēnlièjù).] Mit der gegebenen grammatischen Betonung im Englischen sollte also auch das chinesische Äquivalent eine Hervorhebung des Ortes, also 这里/儿, genießen dürfen, woraus sich mindestens zwei Möglichkeiten ergeben:

• (1) 「她睡觉的是这里」\hspace{0.3em}(s. Zeile 11)
  • Hier wäre eine Voranstellung von 这里 und sodann auch das Einfügen von 就 möglich: 「这（里）（就）是她睡觉的地方」
• (2) 「她就睡在这儿」\hspace{0.3em}(Ohne 是-的 wird 这里/儿 hier indirekt über die Verbalhandlung mittels des Adverbs 就 betont: »Sie schläft genau hier.«/ »She sleeps precisely here.« )

Eine Konsultation unter Muttersprachlern erbrachte, dass eine Konstruktion wie in (2) schon als durchaus angemessen erachtet wird, um eine (wenn auch indirekte) Betonung des Ortes zu forcieren. Ein tentatives Urteil wäre also, (2) als Standard zu setzen.

Zeile 8 und 9 (»she is ready to sleep«):

Man beachte, dass die Vorschläge eine Version mit der Partikel 了 (le) anführen. Diese Partikel ist ein Final-Marker, der darauf hinweist, dass der Sprecher auf eine neue Situation (»Sie ist nun fertig zum Schlafen(-gehen).«) hinweist. Diese Form sollte standardmäßig für diesen Baum benutzt werden. Generell ist allerdings problematisch, ob ein Satz diesen Final-Marker erhält oder nicht. Siehe auch 了-Final-Partikel (REFTODO).

eval [THINK: argument: for wide-coverage shi-de needed?]

Die jetzige (1–3) bzw. angestrebte (5–10) Linearisierung ohne 是-的 liefert gute Ergebnisse und ist tendenziell auch für den Fall aus Zeile 4 geeignet. Dennoch sollte die Möglichkeit, für alle Fälle eine 是-的-Variante zu erstellen, gegeben sein. (Wie sich dies in der RGL-API realisieren lässt, ist aber sehr unklar.) [keine Variante, gezielte Erstellung einer Form! => mit API möglich oder nicht?! In Lexikon verbauen???] Wide-Coverage lässt du außen vor?! Es geht hier zunächst einmal um die API-Möglichkeiten.

Mit schlechter Bewertung:

Allen Fällen dieser Gruppe ergeben mit 是-的 schlechte Linearisierungen. Die Zusammenstellung unterteilt sich in

• Subordination-Konstruktion (1),
• Gattungsnomen (CN – Common noun) mit Relativsatz (RCl) (2–5),
• und Sätze oder Verbphrasen, die mit 结婚 (jiéhūn, heiraten) gebildet werden (6–9).

Subordination, Zeile 1 (»it is uncertain who sleeps«): <<subordinate-1>>

Was den Fall in Zeile 1 betrifft, so urteilt Chen also, dass die Linearisierung unzulässig ist. Auch eine Befragung unter Muttersprachlern ergab, dass das Ergebnis von 1 eher wie eine direkte Übersetzung aus westlichen Sprachen klingt. Sowohl 「\hspace{0.2em}不是确定的谁睡觉」\hspace{0.2em} als auch \hspace{0.2em}「是不确定的谁睡觉」\hspace{0.2em} wurden als schlechte Übersetzungen eingestuft; gut wären hingegen \hspace{0.2em}「不确定谁在睡觉/睡着了」\hspace{0.2em} und 「不能确定谁在睡觉/睡着了」.

#+CAPTION[Strukturgleichheit]: Bearbeitungs-Dilemma

-- B                                  -- C
-- it is uncertain who sleeps         -- it is good that she sleeps
mkUtt                                 mkUtt
 (mkCl                                 (mkCl
  (mkVP                                 (mkVP
   (mkAP                                 (mkAP
    (mkAP uncertain_A)                    (mkAP good_A)
    (mkQS                                 (mkS
     (mkQCl who_IP sleep_V)))))            (mkCl she_NP sleep_V)))))

<<uncertain-who-sleeps>> Daher sollte eine Linearisierung ohne 是-的 stark in Betracht gezogen werden. Beim Vergleich mit dem strukturgleichen Ausdrck (C) »it is good that she sleeps« (siehe Auflistung lst:it-is-foo und Sektion uncertain-who-sleeps) wird aber auch klar, dass hier 是 (「她睡是好事」) wiederum gebraucht wird. Auch die Nominalisierung von 好 zu 好事 ist problematisch.

	engl. Linear.	chin.	Ok?	Vorschlag
B	it is uncertain who sleeps	是不确定谁睡觉的	B	不确定谁睡
C	it is good that she sleeps	是好她睡觉的	B	她睡是好事 ??

\begin{center} \line(1,0){250} \end{center}

Zeilen 2–5 (CN + »who is« + AP/Adjektiv):

In diesen Fällen kann 是-的 bedenkenlos entfernt werden.

\begin{center} \line(1,0){250} \end{center}

Zeilen 6–9 (结婚 mit 和)：

Der Adjektiv-Status A2 von 结婚 im jetzigen lexikalischen Paradigma (married_A2) sollte eigentlich in einen Verb-Status abgeändert werden, denn 结婚 ist eine Verb-Objekt-Kombination (binden 结 jié, Ehe 婚 hūn). Das hätte auch den Vorteil, dass die 是-Kopula, die jetzt durch mkCl, mkQCl, mkCN, mkRCl etc. in Verbindung mit einem Adjektiv-Prädikat hervorgerufen wird, unterbliebe.

• Allerdings dringt die gemeinsame lexikalische Basis der RGL auf den Bezeichner married sowie auch auf die Wortart Adjektiv (A).
• Da der zweite Vorschlag Chens leider geschlechtsspezifisch （\xp{嫁给他} – verheiraten an ihn) ist, käme also letztendlich nur der erste in Frage （和他结了婚的女人）
  • Da wir im Sinne der praktikablen RGL-Nutzung die lexikalische Kategorie A beibehalten wollen, bliebe nur, dass das Verb 结婚 mit dem Perfekt-Marker 了，\hspace{0.1em} also als 结了婚，\hspace{0.1em} in das weiterhin bestehende Paradigma married_A2 »eingeschmuggelt« wird.
  • Das lexikalische Paradigma \inlst$married_A2$ muss mit Informationen über die Präposition 和 versorgt werden, sodass diese bei der Konstruktion durch mkVP, mkCl, mkRCl und mkQCl genutzt werden kann.
    • Dies in den letzten beiden Punkten festgestellten Anpassungen sollten nicht problematisch sein.

Mit mittelmäßiger Bewertung:

Zeile 1 und 3: »she is older than he«, war in anderer Form (»who is older than he«) unter den Entscheidungen gegen die Nutzung von 是-的 aus der Sektion mit guter Beurteilung (siehe Abschnitt besser-kein-shi-de-weil-unbetont) und ist damit als Problem schon erfasst. Dasselbe gilt für Zeile 3, »to be older than he«.

Zeile 2, »student who is a woman«: Dass der Relativsatz nicht mit 是 eingeleitet werden sollte, wurde ebenfalls schon beanstandet und ist abgedeckt. Die im Vorschlag beschriebene Denominalisierung von 女人 zu 女 ist problematisch.

In Zeile 4, »whom does she ask where I sleep«, ist die vormalige betonte Konstruktion per 是-的 schon aufgelöst in eine sequentiell subordinierte (cf. subordinate-1). Das überflüssige 说 (shuō, sprechen) wird über die API-Funktion mkVPSlash eingefügt und muss entfernt werden.

Verwendung notwendig

Zeile 1 und 4 (»it is good that she sleeps«, »that she sleeps is good«):

Auf den Fall in Zeile 1 wurde schon beim Vergleich mit »it is uncertain who sleeps« eingegangen (siehe Abschnitt uncertain-who-sleeps). Der Vergleich zwischen Zeile 1 und 5 in diesem Abschnitt macht aber noch deutlich, dass die optimale Reihenfolge von Teilsätzen im Chinesischen einer strikteren Ordnung unterliegt als z.B. im Englischen. Darauf macht zumindest der Vorschlag Chens aufmerksam, der für beide Fälle (a) »it is good that she sleeps« und (b) »that she sleeps is good« derselbe ist, nämlich \hspace{0.2em}「她睡是好事」.

Während die aktuelle Linearisierung von (b) in Chinesische, (c) \hspace{0.2em}「她睡是好的」, immerhin mittelmäßig ist, so ist die von (a) \hspace{0.2em}「是好她睡觉的」\hspace{0.2em} inakzeptabel. Es wäre noch zu ergründen, ob die exakte Umkehr von (c), \hspace{0.2em}「好的是她睡（觉）」， akzeptabel ist, denn generell sind Äquationen umkehrbar.[fn:: Cf. \cite[245]{yip_chinese:_2004}: »Rosen sind am schönsten.«/ »Am schönsten sind Rosen.« \hspace{0.2em}「玫瑰花是最美的」\hspace{0.2em}/ \hspace{0.2em}「最美的是玫瑰花」.] Wenn dem so ist, dann wäre dies ein guter Kompromiss für die Bibliothek, da so die verschiedenen Reihenfolgen doch abbildbar wären.

Zeile 2 (»it is she who sleeps«) ist ein simpler Fall von Äquation, der 是 notwendig macht.

Zeile 3 (»not everybody«) zeigt deutlich, dass 不 nicht allein attributiv einem NP untergeordnet werden kann. Es braucht vielmehr immer ein Verb, auf das es sich beziehen kann; und wenn kein besonderes Verb vorhanden ist, dann muss 是 angenommen werden. Beachtenswert an diesem Verhalten ist außerdem, dass der Satz seine attributive Struktur (das 的 entfällt) verliert und so eine prädikative Struktur annimmt. Eine Verbesserung sollte nicht problematisch sein.

»Zeitformen« und Aspekt

Im Chinesischen sind keine grammatischen Tempi in der Morphologie der Verben verankert. Stattdessen wird die Relation zur Sprechzeit mit Zeitadverbien (morgen 明天 míngtiān, letztes jahr 去年 qùnián, bald 快 kuài) oder speziellen Hilfsverben (wollen/werden 要 yào) ausgedrückt. Sehr wohl gibt es aber Verb-Markierungen, welche die Abgeschlossenheit (Perfektiv) einer Handlung ausdrücken, darunter etwa der Aspekt-Marker 了 le. Bei einem Satz, der keine weiteren Zeitadverbien enthält, wie \hspace{0.2em}「我买了三本书。」\hspace{0.1em} Wǒ mǎile sān běn shū und auch sonst keinen weiteren zeitlichen Kontext bietet, kann dann vom Perfektiv auf ein Vergangenheitstempus geschlossen werden, sodass wir etwa mit dem dt. Perfekt übersetzen können: »Ich habe drei Bücher gekauft.«

Ein weiterer wichtiger Aspekt ist der Progressiv, der sich aus dem Bereich ergibt, den der Perfektiv unberücksichtigt lässt, nämlich den der nicht-abgeschlossenen Handlungen (Imperfektiv). Bevor die RGL-Tabelle der Aspekte behandelt wird, soll auf den Progressiv besonders eingegangen werden, da die ersten beiden Einträge der Tabelle den Progressiv behandeln.

Exkurs: der Progressiv im Chinesischen

Progressiv und Durativ

Der Progressiv wird im Chinesischen in Unterkategorien aufgeteilt werden, die sich aus den Funktionen der eben schon angesprochenen Indikatoren 在 und 着 ergeben. Diese beiden Unterkategorien setzen verschiedene Akzente bei der Beschreibung des imperfektiven Aspekts einer Handlung: Während (a) mittels 在 dem Subjekt der Handlung vom Sprecher zugestanden wird, dass es derzeit (gerade) dabei ist, eine gewisse Handlung auszuführen, wird mittels (b) ein Andauern der Handlung selbst bzw. eines durch die Handlung erreichten Zustandes beschrieben.

[fn:neutral] Dies ist die wort-wörtliche Übersetzung, die ugs. wäre: »Sie bereitet gerade den Unterricht vor.« Dem hier benutzten gerade entspricht (wort-wörtlich) aber erst 正/正在, auch wenn 在 allein auch schon als gerade interpretiert werden kann. Siehe Punkt 6 dieser Liste.

Besonders deutlich kann sich dieser Unterschied zeigen, wenn andere Sprachen für ein und dasselbe chinesische Verb, das entweder mit 在 oder 着 markiert ist, zwei verschiedene Verben übersetzen. Ein hierfür immer wieder vorgebrachtes Beispiel betrifft das Verb 穿 chuān, das soviel wie durchbohren, engl. to pierce through, bedeutet, weil hier vermittels der Zähne 牙 yá (eines Nagetiers?) ein Loch 穴 xué gebohrt wird. Benutzt wird 穿 aber auch im Kontext von Kleidungstücken:

a. \xp{他在穿大衣}。

Er zieht gerade den Mantel an. – He is (just) putting on his coat.[fn:at_gerade-trans]

• Er ist (gerade) dabei, den Mantel anzuziehen. (dabei = inmitten einer Handlung)

b. \xp{他穿}\xpinyin{着}{zhe}\xp{大衣}。

Er trägt einen Mantel. – *(He wears a coat.)[fn:at_star] / He is wearing a coat.

In (a) wird die Verbalhandlung 穿 durch ein vorangestelltes 在 modifiziert. Das Resultat dieser Modifikation ist eine kombinierte Verbalhandlung, deren Bedeutung als `inmitten des Durchbohrens’ oder `beim Durchbohren’ paraphrasierbar ist. Für die grundlegende Bedeutung durchbohren bietet das Deutsche im Kontext von Kleidungsstücken u. a. das sehr geläufige Verb anziehen, das den Vorgang beschreibt, wie man ein Kleidungsstück an seinen Körper (heran-)\emph{zieht} und es dort belässt.[fn:: Ein weiteres Verb wäre schlüpfen, das vielleicht die Grundbedeutung von 穿 (im Kleiderkontext) am besten wiedergibt, denn es kann sowohl im Kontext von Nagetieren, wie in `die Maus schlüpfte schnell in oder durch das Loch’ (das sie zuvor evtl. selbst gebohrt/genagt hat), als auch im Zusammenhang mit Kleidungsstücken, in die man sich zunächst hineinbohren muss (bevor man sie mit sich herumtragen kann), genutzt werden: `Er schlüpfte in den Mantel’ (und er passte ihm wie angegegossen / 大衣非常合身).] Setzen wir anziehen in den Progressiv, der im Deutschen vielfach mit dem Adverb gerade gebildet, dann haben wir eine adäquate Übersetzung. Gleichermaßen hält das Englische für die Bedeutung von 在穿/\emph{beim Anziehen} das Verb to put on bereit.

Ganz anders nun in Fall (b), in dem nun der (anhaltende) Zustand mittels 穿着 beschrieben wird, der nach dem Anziehen des Mantels in kraft tritt. Da anziehen und put on diesen Sachverhalt alleine nicht wiedergeben können bzw. einfach nicht dafür konzipiert sind, muss auf andere Verb, nämlich tragen und wear, ausgewichen werden.

Aspekt und Aktionsart (viewpoint/situation aspect)

Im Gegenssatz zum Verb anziehen, das ein Ende der ihm eigenen Handlung (das Kleidungstück ist irgendwann an dem Körper angelangt) andeutet,[fn:: Siehe \cite[55f.]{xiao_aspect_2004}: Verben, die das Erreichen eines Zustandes intern kodieren, werden als achievement verbs bezeichnet.] deuten tragen und wear nun auch auf einen kontinuierlichen, durativen Zustand hin. Dass Verben in dieser oder jener internen Zeitstruktur organisiert sind, fällt gemeinhin unter die Kategorie der Aktionsart eines Verbs, die explizit im Gegensatz zu der Kodierung mittels grammatischer Aspekt-Partikel gesehen wird. In welchem Maß nun Sprachen die Aspektualität[fn::\cite[1]{zhang_contrastive_1995} führt diesen Sammelbegriff für Aspekt und Aktionsart ein.] einer Verbhandlung mittels lexikalischer oder grammatischer Mittel ausdrücken, ist sehr unterschiedlich und das Beispiel von 穿 legt beredtes Zeugnis davon ab.[fn:: Die Unterscheidung zwischen Aspekt und Aktionsart wird seit \cite{smith_parameter_1991} in der englischen Literatur vermehrt unter Begriffen viewpoint aspect und situation aspect abgehandelt.]

Nun mag es klar erscheinen, dass 在 immer eine gerade-andauernde Handlung beschreibt, während 着 einen kontinuierlichen Zustand kodiert, aber beide durch diese Marker entstehenden Lesarten können wiederum modifiziert werden. Hier exemplarisch für 着:[fn:: Beispiel übernommen samt engl. Übersetzung aus \cite[199]{xiao_aspect_2004}.]

(1) 着 – Post-Kulmination

\xp{马医生为防不测}，\xp{整天穿}着\xp{防弹背心}。

• In order to guard against the risk of being shot, Dr. Ma was wearing his body armour all day long.
• Um allen Eventualitäten vorzubeugen, trug Dr. Ma den ganzen Tag über eine schuss-sichere Weste.

(2) 着 – Pre-Kulmination

\xp{听}\xpinyin{到}{dao}\xp{急救领响}，\xp{马医生穿}着\xp{大衣冲向急救室}。

• At the emergency bell, Dr. Ma rushed towards the first-aid rom while he was still putting on his overcoat.
• Als er die Alarmsirene hörte, stürmte Dr. Ma seinen Mantel überwerfend in Richtung Notfallaufnahme.

Die Übersetzungen für (1) zeitigen, wie zu Erwarten, die Bedeutung von 着 als tragen, während (2) trotz 着 mit der Phase vor dem Tragen, also noch mit dem Anziehen, beschäftigt ist, und damit die Phase einnimmt, die eigentlich mit 在 assoziiert ist. Bei (1) wird der durative Aspekt des Tragens vor allem über 整天 zhěngtiān, den ganzen Tag, hergestellt, und bei (2) evoziert die dynamische Situation des Stürmens in eine Richtung, in der 穿着 benutzt wird, die Lesart der Phase des Anziehens bzw. wort-wörtlich des Hineinbohrens.

Das letzte Beispiel sollte auf eine sehr feine Deutungsunterschiede aufmerksam machen, die beim Gebrauch von 着 entstehen können. Von diesen sehr feinen Unterschieden aber einmal abgesehen, können wir weitere grobe Charakteristika über die Verwendung von 在 und 着 festhalten, was hier nun in Listenform geschieht:

[fn:at_gerade-trans] Die deutsche Übersetzung wurde gewählt, weil sie in diesem Fall (d. h. dieses Verb betreffend) m. E. die gebräuchlichste und kürzeste Variante in einem gesprochenen Dialog ist. Andere mögliche Varianten, wie »Er ist dabei, den Mantel anzuziehen.« oder »Er ist beim Mantel anziehen.« weisen zwar (wie noch zu zeigen sein wird) eine in gewisser Hinsicht bessere (wie sich zeigen wird: wort-wörtliche) Übersetzung auf, aber es kann doch etwas weitschweifig und allzu literarisch wirken.

Siehe aber auch \cite{gargyan_am-progressiv_2010}, die die Gebräuchlichkeit des am-Progressiv (»Er ist am Schreiben eines Artikels.«) nachweist und auch versucht diesen als hinreichend grammatikalisiertes Phänomen zu verorten.

[fn:at_star] Alle anzweifelbaren bzw. unakzeptablen Sätze oder sonstige Einheiten von Sätzen sind mit einem Stern gekennzeichnet. In diesem Fall mag die Version ohne die Präsens-Progressiv-Kennzeichnung des Englischen (Form von be ++ Verb + ing – i.e. present progressive/continious) (vor allem auch aus dt. Perspektive) Sinn machen, weil »wear« (genauso wie »tragen«) einen andauernden Zustand beschreibt. Es scheint jedoch im Englischen eine gewisse Tendenz zu geben, solche Zustandsverben in das Präsens Progressiv zu setzen. Cf. \cite[6]{bland_present_1986}: »I’m wearing a jacket.« und deswegen ist die unmarkierte Version sehr zweifelhaft.

Zusammenfassung: Progressiv und Durativ

a. \xp{进行体}/\xp{态} – »Progressiv« mittels 在 (Kurrentiv)

Der Sprecher behauptet gegenwärtige Involvierung des Satz-Subjekts in einen voranschreitenden Prozess mittels 在 \hspace{0.2em}（她在备课。 / Sie ist dabei, den Unterricht vorzubereiten.[fn:neutral] / She is preparing her lessons.）. [fn:eng-no-disamb-etc]

1. Die Abhandlung von 在 in dieser Kategorie ist assoziiert mit den ebenfalls als Progressiv-Indikatoren eigestuften Markern \xp{正} (gerade, engl. just, kann auch ein anderes Verb als 在 modifizieren)，\xp{正在} (gerade dabei), \xp{现在} （/jetzt/ dabei）und \xp{呢} (als Satzfinalpartikel[fn:: Der zusätzlich einen rhetorischen Ton anschlägt (\cite[105]{yip_chinese:_2004}) bzw. eine feste Überzeugung \cite[123]{motsch_grundlagen_2010} ausdrückt: »外面在下雨呢。/ (Don’t you know) it’s raining (outside).«]
2. 在 u. a. im Dt. paraphrasierbar als »dabei (sein), etwas zu tun« / »(to be) in the process of verb-ing« (postulierter universal-sprachlicher Lokativ[fn:: Cf. \cite[132]{bybee_evolution_1994}.])
3. letztere Beschreibung (2) macht zugleich deutlich, dass ein aktiver Akteur im Satz vorhanden sein muss oder angenommen werden kann (Subjekt-Forderung), d. h. es wird ein Individuum gefordert, das etwas tun kann bzw. dessen innerer psychologischer Zustand dargestellt werden kann. Dieser Zustand darf keine fest Disposition ausdrücken, sondern darf nur eine gewisse Phase sein:
   • 在熟睡 – jmd. ist fest am Schlafen / 在热恋 – jmd. ist total verknallt / passionately in love
   • *在聪明/笨/高/小 – jmd. ist dabei intelligent/groß/klein zu sein – cf. engl. »he’s being stupid« (Progressiv möglich, aber drückt vielmehr die Absicht des Individuums aus, eine gewisse Disposition zur Schau zu tragen, und weniger den Verlauf der Handlung.)
4. aus (2) und (3) lassen sich charakteristische Satzmuster ableiten[fn:: Nach \cite[105f.]{yip_chinese:_2004}]

   Akteur + 在 + Aktionsverb

   \xp{演员们}+在+\xp{排演}。 / The performers are rehearsing.

   Akteur + 在-Lokativ + Aktionsverb

   \xp{小猫}+\xp{在火炉前}+\xp{打瞌睡}。 / The kitten is dozing in front of the fire.[fn:: \cite[468f.]{liu_danqing_yufa_2008} weist darauf hin, dass sich 在 als Progressiv-Indikator aus der Abkürzung der halb-funktionalisierten Lokalangabe »dort« (半虚化的“在那儿”) entwickelt haben könnte. Dieser Hinweis ebenso von \cite[106]{yip_chinese:_2004} und \cite[162]{cheung_practical_1994}. Siehe dazu auch der Begriff »stage property« (\cite[45,358]{smith_parameter_1991}), den \citeauthor{xiao_aspect_2004} mit 在 als Lokativ im Einklang sehen \citep[215]{xiao_aspect_2004}.]

5. Position von 在 nicht unbedingt vor dem Hauptverb, sondern auch vor eventuellen Koverben/Präpositionen, die zur Verbalhandlung gehören (»I am writing to a friend of mine in the USA.« / \hspace{0.1em}「我 在 给 一 个 在 美国 的 朋友 写信。」[fn:: Cf. \cite{sharoff_leeds-internet-zh_2005}, Suchstring: \verb+「我 在 给 一 个 在 美国」+.])
6. 在 als Progressiv-Indikator ist selbst wieder modifizierbar durch Zeitadverbiale und kann so auch Aspekte ausformen, die dem Durativ nahe stehen, zum Beispiel:

   \xp{正} →

   她正在备课。 / Sie ist gerade dabei, die Unterrichtsstunde vorzubereiten. / She’s just preparing the lesson. (正 verstärkt den Progressiv)

   \xp{经常} →

   她经常在练习。 / Sie ist konstant dabei zu üben. / She’s constantly exercising. (Habituativ, Frequentiv)[fn::Dieses und das nächste Beispiel von: \cite[583]{fang_yuqing_shiyong_1992}.]

   \xp{一直} →

   她一直在试验。 / Sie ist immer(zu) am Experimentieren. / She is always experimenting. (Habituativ, Frequentiv)

   Negation (selten) →

   不在 oder 没（有）（在） [fn:: Siehe \cite[28]{motsch_grundlagen_2010}: bei Nutzung von 没（有） könne 在 entfallen. \cite[107]{yip_chinese:_2004}: »The negation of the continuation aspect is usually effected by the use of 不 with bù with 在 zài (but not 正在 zhèngzài)«, woraufhin einige Beispiele folgen, darunter auch eines, was die Nutzung in der Vergangenheit zeigt (「上星期天下午我不在看球在。」\hspace{0.1em} – »I wasn’t watching a match last sunday afternoon.«). \cite[53]{xiao_zhonghua_richard_negation_2008}: »[…] the durative aspect marked by -/zhe/ and the progressive aspect marked by zai rarely occur in negative sentences. […] While sentences taking zai can be negated by either bu or mei, cooccurences of bu and zai are typically in double negation structures or rhetoric questions, which are essentially positive in meaning.«]

7. größtensteils inkompatibel mit Komplementen des Resultats, weil diese einen natürlichen Endpunkt für die gerade andauernde Handlung bedeuten würden[fn:: Vgl. \cite[763]{klein_aspect_2000}. Dennoch in bestimmten Fällen Resultat auch als Prozess auffassbar \citep[213]{xiao_aspect_2004}: 「我们正在打赢这场战争。」\hspace{0.1em} – »Gerade gewinnen wir den Krieg.«; \hspace{0.1em}「一批有远见卓识的民营企业家们正在为此作出艰辛的努力。」\hspace{0.1em} – »Eine Gruppe weitsichtiger (Privat-)Unternehmer unternahm zu diesem Zweck große Anstrengungen.«]

b. \xp{持续体}/\xp{态} – Durativ mittels 着

Fortsetzung eines durch die Verbalhandlung erreichten Zustandes (Der Mantel wurde von jmd. anzogen und nun wird er von diesem jmd. getragen.) bzw. eine genrelle Kontinuierlichkeit der Handlung; drei Funktionen im Einzelnen:[fn::Nach \cite[182]{xiao_aspect_2004}.]

1. Okkurenz mit einem Verb oder Adjektiv zur Anzeige der Kontinuierlichkeit von dynamischen oder statischen Situationen
   • 「“九号工程”建成20多年来，一直空闲着。」\hspace{0.1em} (statisch) – »Mehr als 20 Jahre sind seit der Fertigstellung von `Projekt Nr. 9’ vergangen, seither liegt es durchgehend brach/ist es durchgehend inaktiv.«
   • 「他正盘算着脱身之计。」\hspace{0.1em} （dynamisch） – »Gerade war er am Nachdenken über einen Fluchplan.«
2. (V1+着+V2) In Verbund mit einem Verb (V1) bildet 着 ein Adverbial, das ein anderes Verb dann modifiziert. Das Adverbial bietet so Hintergrund-Informationen oder stellt überlappende Verbhandlung dar:
   • 「吃着吃着饭猛力将饭桌一掀。」\hspace{0.1em} – »Sie aß und aß bis sie plötzlich den Tisch rabiat umschubste.«
3. Satz ist in lokativer Inversionstellung und 着 impliziert existentiellen Status: -「 荒山上\xp{矗立}着一座古老的\xp{碉楼}。」\hspace{0.1em} – »Auf dem kargen Hügel ragt ein antiker Diaolou-Turm empor.«

• Modifikationen:

  Negation (selten) →

  没（有）（着）[fn:: \cite[308]{cheung_practical_1994}: \hspace{0.1em}「信封上没写着名字。」\hspace{0.1em} – »There is no name written on the envelope.«, \cite[54]{xiao_zhonghua_richard_negation_2008}: »Sentences taking -\emph{zhe} are negated more frequently by mei than bu, and -\emph{zhe} is often omitted in negative sentences unless it appears in the V-\emph{zhe} V structure where V-\emph{zhe} acts as an adverbial.«]

[fn:eng-no-disamb-etc] Man beachte, dass der Term Progressiv vielfach mit dem Sinn von (a) und (b) zugleich aufgeladen ist, wir aber für diese Kategorie (a) explizit nur den gegenwärtig laufenden Prozess, in dem sich ein Subjekt befindet, fokussieren wollen. Um explizit auf (a) zu verweisen zu können, werde ich den Term Kurrentiv verwenden.

Hier ein Beispiel für den Zusammenfall von (a) und (b): 1. Sowohl (a) und (b) sind kontinuierlich und imperfekt. 2. Daher treten sie auch oft zusammen in einem Satz auf, was 3. wiederum bedeuten kann, dass die beiden Funktionen nur im Kontext sichtbar werden: Im Englischen ist »He is reading Ulysses.« an sich zweideutig. Der Kontext müsste zeigen, ob er wirklich gerade liest, oder ob er aus Studiengründen mit dem Lesen dieses Buches begann, das Lesen aber noch nicht abgeschlossen, sondern nur unterbrochen hat, um gerade etwas völlig anderes zu tun. (Beispiel von https://en.wikipedia.org/wiki/Continuous_and_progressive_aspects) 4. Im Gegensatz zu der (generellen) Ambiguität im Englischen impliziert 在 nun aber in Fällen wie \hspace{0.2em}「他在穿大衣」\hspace{0.2em} verstärkt den Kurrentiv, denn (wie oben schon gezeigt) wäre eine Übersetzung mit gerade/just im Deutschen respektive Englischen naheliegend: (g) »Er zieht gerade den Mantel an.« / »He’s just putting on the coat.« (Cf. \cite[161]{fan_kaitai_xiandai_2000}) 5. Woher kommt nun der verstärkte kurrentive Sinn von 在 im Chinesischen? Eine erste Intuition dafür liefert die Paraphrasierung von (g) in »Er ist im Begriff, den Mantel anzuziehen.« / »He’s in the process of putting …«

[fn:liu-dur] \cite[467f.]{liu_danqing_yufa_2008}(b), S. 467, Durativ mit 着, diskutiert Liu Zustandsverben (静态动词)，wie sitzen, liegen, tragen (走着，躺着，提着) und Tätigkeitsverben (动态动词), die im Muster Lokativ + Verb + 着 + Nomen vorkommen (墙上挂着一幅画儿，地上写着一个大字). Er erwähnt, dass der Satz 他在房间里挂着画, in dem 在 als Teil einer Ortsangabe vorliegt, zweideutig ist: \hspace{0.2em}「既可表正在挂，也可以表画挂上后持续存在的状态。」.

Ganz anders hingegen ist die Einteilung bei \cite{yip_chinese:_2004}: In ihrem deskriptiven Satzmodell weisen sie 在 zwar eine kurrentive Funktion zu (S. 303: »[…] what is going on through the action of the verb at the moment of speaking […]« (meine Hervorhebung)), aber wenn es im Verbkapitel um die Besprechung der Aspekt-Partikel 在 an und für sich geht, dann zeigt sich an dieser eine zusätzliche durative Seite (S. 105: »[…] the action indicated can be ongoing, continual, or repetitive.«). So übersetzen sie etwa 小猫在火炉前打瞌睡 in »The kitten is dozing in front of the fire.« und beschreiben die Wirkung des »Koverbs« 在 in der Ortsangabe 在火炉前 als »express[ing] continuous action« (S. 106).

\cite[304]{yip_chinese:_2004} geben für solche Fälle an, dass die Funktion von 在 als Aspekt-Partikel vorliegt. Als wahrscheinlichen Grund hierfür sehen sie (S.106), dass die 进行-Funktion von 在, ebenso wie schon von Liu erwähnt, von der Nutzung in Orsangaben herrührt. Ihre Definition der Funktionen von 在 beinhaltet sowohl 进行 als 持续 umfasst

Weiterhin zu den beiden Fällen auch bei . Sowie für (b): 着 markiert »[…] a state that has resulted from the action of the verb.« (S. 303) betont aber auch (S. 305) die Verbalhandlung selbst (»calls attention to the action itself, and therefore carries a descriptive flavour.«)

\cite[304]{yip_chinese:_2004}: (a) »[…] 在 zài indicates ongoing action on the part of the subject.« Diese Aussage bezieht sich auf das Beispiel \hspace{0.1em}「王老师在备课。」

Tabelle-Daten

Zeile 1–2: (»to be sleeping« , »it is raining«)

In Fall 1 gibt es zwei Vorschläge: (a) 在 (zài) vor dem Verb, 在睡, oder (b) 着 (zhe) nach dem Verb, 睡着. Vorschlag (a) wurde in der Zwischenzeit in der API-Funktion progressiveVP umgesetzt, sodass auch Fall 2, der dieselbe API-Funktion nutzt, diesen Vorschlag übernimmt. Im folgenden sehen wir uns zunächst an, wie gut 在 in progressiveVP funktioniert (v.a. interessiert hier, ob es möglich ist 在 vor die komplette Verbphrase zu stellen, wie in \hspace{0.1em}「她给朋友写信。」\hspace{0.1em} – »Sie schreibt einem Freund einen Brief.«) Und danach schauen wir, ob es noch eine Möglichkeit gibt 着 aufzurufen.

progressiveVP mit 在

Die API-Funktion progressiveVP verweist auf die Kern-Funktion ProgrVP, die sich in IdiomChi.gf befindet. Diese Funktion nimmt einen VP und produziert einen weiteren VP, in dem 在 ausgehend von zai_s als reguläres Verb in das record-label verb (Z. 3) gepackt wird. Die Bestandteile des Argument-VP werden hingegen in das record-label compl gesteckt.

ProgrVP   : VP -> VP ;     -- be sleeping // Typendefinition aus abstract/Idiom.gf
ProgrVP vp = {
  verb = regVerb zai_s ;
  compl = vp.prePart ++ vp.verb.s ++ vp.compl ;
  prePart, topic = []
  }

Mit der eben beschriebenen Aufteilung in verb und compl ist dann auch sichergestellt, dass 在 vor dem gesamten VP steht:

> cc mkUtt
      (progressiveVP
       (mkVP
        (mkV3 "写") (mkNP (friend_N)) (mkNP (mkN "信"))
       ))
{s = "在" ++ ("朋" ++ "友") ++ "写" ++ "信"}

Was nun noch fehlt, ist die Präposition/das Koverb 给 (geben/an, gěi), das hinter 在 bzw. vor 朋友 (Freund, péngyou) stehen muss. Dies zu implementieren, sollte nicht problematisch sein.

Kann 着 (Durativ) benutzt werden?

Laut TenseChi.gf gibt es sechs Kernfunktionen (TPres, TPast, TFut, TCond, ASimul, AAnter) für die jeweiligen Zeitformen, die eine (mehr oder weniger sinnvolle) Zuordnung zu den chinesischen Aspektformen vornehmen (etwa TPast → APerf):

#+CAPTION[Tense-Aspect-Mapping]: »Integration« der Aspekte in der RGL-Tempus-Formen

TPres  = {s = [] ; t = APlain} ;   -- API-Funktion `presentTense'     ruft `TPres'
TPast  = {s = [] ; t = APerf} ;    -- API-Funktion `pastTense'        ruft `TPast'
TFut   = {s = [] ; t = ADurProg} ; -- API-Funktion `futureTense'      ruft `TFut'
TCond  = {s = [] ; t = ADurStat} ; -- API-Funktion `conditionalTense' ruft `TCond' 

ASimul = {s = [] ; t = APlain} ;   -- API-Funktion `simultaneousAnt'  ruft `ASimul'
AAnter = {s = [] ; t = APerf} ;    -- API-Funktion `anteriourAnt'     ruft `AAnter'

Diese Kern-Funktionen können wiederum von der API-Ebene aus aufgerufen werden (wie in den Kommentaren oben beschrieben). ADurStat könnte mit dem statischen Zustand zu tun haben, den 着 mit Verben, wie 穿 in 穿着衣服 （/chuānzhe yīfu/, »Kleider tragend«）, beschreibt. Schauen wir einfach mal, ob conditionalTense etwas mit 着 zu tun hat:

> cc mkS conditionalTense (mkCl (mkVP( mkV3 "写") (mkNP(friend_N)) (mkNP(mkN "信"))))
$\Downarrow$ {s = ("朋" ++ "友") ++ ("写" ++ "着") ++ "信"}

Augenscheinlich ja, denn 着 wird nach dem Verb des Satzes eingefügt. Hier noch ein sinnvollerer Satz in lokativer Inversionsstellung: »Auf der Straße steht ein Name geschrieben.«

> cc mkS
      (mkAdv on_Prep
             (mkNP road_N))
      (mkS conditionalTense
           (mkCl
            (mkVP write_V2
                  (mkNP name_N))))

$\Downarrow$ {s = ("在" ++ "路" ++ "上") ++ ("写" ++ "着") ++ "名" ++ "字"}

Leider lässt sich bislang nicht von der API-Ebene aus auf den Erfahrunsaspekt (Perfektiv eines persönlich relevanten Ereignisses: \hspace{0.1em}「我去过德国。」\hspace{0.1em} – »Ich habe schon einmal Deutschland besucht.«) zugreifen. In der unterliegenden Kernfunktion ist er aber voll zugänglich:

#+CAPTION[useVerb-core-function]: Die Kern-Funktion zur Verwendung von Verben

useVerb : Verb -> Polarity => Aspect => Str = \v -> 
  table {
        Pos => table {
          APlain   => v.s ;
          APerf    => v.s ++ v.pp ;
          ADurStat => v.s ++ v.ds ;
          ADurProg => v.dp ++ v.s ;
          AExper   => v.s ++ v.ep   -- experiential aspect
          } ;
        -- [...]
   } ;

»it is raining«

<<split-verb-object>> Ein alternativer Vorschlag von Chen für den zweiten Fall ist noch, auch hier den durativen Aspekt mit 着 zu benutzen (下着雨). Hier ist es sehr klar, dass der Partikel zwischen die eigentliche Verbsilbe (niedergehen, unten 下 xià ) und das eigentliche Objekt muss (Regen 雨 yǔ). Die ist jedoch mit dem jetzigen Lexem rain_V0 nur schlecht möglich, da sowohl Verb als auch Objekt schon in einem »record-label« stecken:

> cc rain_V0
$\Downarrow$ {s = "下" ++ "雨"; [...]}

Idealerweise sollten die Konstituenten des record-labels s auf zwei verschiedene aufgeteilt sein. (RGL-TODO:) Eine Abschätzung über diese Möglichkeit sollte erfolgen.

Zeile 3: (»John, who walks«)

Wieder der Trick mit dem conditionalTense (um Chens Vorschlag zu realisieren):

> cc mkUtt (mkNP (mkNP john_PN) (mkRS (mkRCl which_RP (mkVP walk_V))))
$\Downarrow$ {s = ("走" ++ "的") ++ "约" ++ "翰"}

> cc mkUtt (mkNP (mkNP john_PN) (mkRS conditionalTense (mkRCl which_RP (mkVP walk_V))))
$\Downarrow$ {s = (("走" ++ "着") ++ "的") ++ "约" ++ "翰"}

Zeile 4, 5, 7, 6: »she hadn’t seen«, »whom does she know that we hadn’t seen« …

Die ersten beiden Fälle behandeln das engl. Past Perfect (pastTense, anteriorAnt) und drücken eine Negation aus. Der eminente Fehler in der chinesischen Linearisierung ist, dass der falsche Verneinungspartikel (不 anstatt 没) benutzt wird und dass, wenn diese Verneinung des Perfekt geschieht, der Perfekt-Marker 了 nicht entfällt. Dieser Fehler entsteht durch falsche Definitionen in der schon gezeigten Kernfunktion useVerb aus dem Modul ResChi.gf (nur diesmal im Negationsteil):

useVerb : Verb -> Polarity => Aspect => Str = \v -> 
  table {
    Pos => table {
      -- [...]} ;
    Neg => table {
      APlain   => v.neg ++ v.sn ;
      APerf    => "不" ++ v.sn ++ v.pp ;   -- Korrektur zu: "没" ++ v.sn
      ADurStat => "不" ++ v.sn ;           -- Hier auch 没. (Siehe Durativ-Besprechung: 
      ADurProg => v.neg ++ v.dp ++ v.sn ;  --               Modifikation/Verneinung)
      AExper   => v.neg ++ v.sn ++ v.ep
    }} ; 

In der Auflistung in Zeile 7, wo der perfektive Aspekt (APerf) abgeglichen wird, müssten die angezeigten Änderungen vorgenommen werden. Fall Nr. 7 ist zwar nicht im Past Perfect, greift aber genauso auf useVerb zurück. Fall Nr. 6 (»who wouldn’t have slept«) hat auch Probleme mit der Verneinung, die wie schon gezeigt, gelöst werden sollten. Die Art und Weise, wie das Konditional im Chinesischen hervorgerufen wird, überlässt man vielleicht besser dem (Satz-)Kontext. (Chens beredter Vorschlag ist auch ihm noch zweifelhaft. Andererseits ist 可能 (kěnéng – vielleicht, möglich) ein exzellentes Signalwort für Wahrscheinlichkeit und er verwendet es auch noch als Vorschlag in »she wouldn’t have slept« [nicht hier abgebildet].)

Zeile 8: »she has slept«

Hier tritt wieder das Problem von Abschnitt split-verb-object auf: Bei Verben, die Verb-Objekt-kombiniert sind, muss eine Splittung der Konstituenten erfolgen können, sodass der Marker in die Mitte kann (oder das Objekt entfällt komplett, wie in diesem Fall von Chen gezeigt).

Zeile 9, 10: Futur

Hier wird der Progressiv benutzt, aber das dürfte weniger passend sein im Chinesischen. Chens Vorschläge: Unmarkiertheit oder Markierung mit Hilfsverb (会 huì – können, werden) sollten umgesetzt werden.

Konklusion

Im Zuge dieser Evaluation wurde das GF-RGL-System anhand verschiedener grammatischer Konstruktionen beleuchtet. Dabei traten viele Ungereimtheiten in den Details des grammatischen Zusammenwirkens zu Tage. Manche Probleme sind allzu schwierig, wie etwa der Wandel 好 zu 好事 in Sektion 4.3.2. Und auch die in der letzten Sektion angesprochene Problematik des Einfügens von Aspekt-Markern in Verb-Objekt-Kombinationen ist ein Problem, was man besser schon hätte bei Beginn der Chinesisch-RGL-Implementierung bedenken sollen. Dennoch wurden die meisten der hier betrachteten Probleme als behebbar eingestuft und Lösungsmöglichkeiten dazu anhand des Quelltextes aufgezeigt.

Konditional

Komplement des Resultats (结果补语)

• shi-de – »Buch ist ausverkauft«?- es scheint noch nichts dafür definiert zu sein
• versuche Satz zu bilden: “Dieses Buch ist ausverkauft”
• ~/d/n/G/l/s/chinese git:master ❯❯❯
• gf AllChi.gfo
• AllChiAbs> p “这 本 书 卖 光 ” => The sentence is not complete
• tab comletion after guang -> guang hua 光滑:

LexiconChi.gf 182:smooth_A = mkA “光滑” ;

sysu/Assign_4.gf 425:glaze_V = mkV “变得光滑” ; – 1

sysu/Assign_6.gf 27:glossy_A = mkA “光滑” ; – 7

• Satz müsste eher mit 售完 gebildet werden! (noch nicht in RGL-Chi)
• und dann ist auch die Frage, ob shi…de dafür benutzt wird, wahrscheinlich schon: 这本书是售完的. (Beschreibung Motsch, S. 127: “Betonung der Eigenschaft des Beschriebenen”), es geht aber auch: »这本书已售完« (Shanghai Dt-Chin., 134)

Tabellen-Daten für Appendix?

\printbibliography

zotero

Header :ARCHIVE: