Wissensbasierte Textverarbeitung: Schriftsatz und Typographie

Home -> Wissensbasierte Textverarbeitung -> 2. Schriftsatz
 
Chapters
Einführung
Typographie
Schlußbemerkungen
Literaturhinweise
Anhang
 

2 Schriftsatz

"Wenn ein Autor sein Manuskript zur Drucklegung vorbereitet, wird er den Verleger über Besonderheiten und Schreibweisen seines Werkes unterrichten. Das im Verlag eingehende Manuskript wird überprüft und in der Regel von einem Lektor oder Redakteur inhaltlich, stilistisch und sachlich bearbeitet." (/Duden DT5/, S. 41; Unterstreichung von mir)

Bei der Herstellung von Drucksachen sind Richtlinien (/Duden DT5/, S. 45) zu beachten, die z.B. folgenden Aufbau besitzen:

Abkürzungen

a) Am Satzanfang

Abkürzungen, die für mehr als ein Wort stehen, werden am Satzanfang in der Regel ausgesetzt.

Zum Beispiel hat ... (für: Z.B. hat ...)

Mit anderen Worten ... (für: M.a.W. ...)

b) S., Bd., Nr., Anm.

Abkürzungen wie S., Bd., Nr., Anm. sollen nur verwendet werden, wenn ihnen kein Artikel und keine Zahl vorangeht.

S.5, Bd.8, Nr.4, Anm.B;

aber: die Seite 5, der Band 8, die Nummer 4, die Anmerkung B; 5. Seite, 8. Band, 4. Nummer.

c) Mehrgliedrige Abkürzungen

Bei mehrgliedrigen Abkürzungen wird zwischen den einzelnen Gliedern nach dem Punkt ein kleinerer Zwischenraum gesetzt.

z.B., u.v.a.m., i.V., u.dgl.m.

Die Trennung mehrgliedriger Abkürzungen ist zu vermeiden.

nicht: Die Hütte liegt 2800 m ü.
d.M.

sondern: Die Hütte liegt 2800 m
ü.d.M.

Auch abgekürzte Maß- und Währungseinheiten sollen nach Möglichkeit nicht von den dazugehörigen Zahlen getrennt werden.

nicht: Wir bestellten für 590
DM Gardinenstoff.

sondern: Wir bestellten für 590 DM
Gardinenstoff.

Neben den Abkürzungen gibt es noch Richtlinien für:

  • Anführungszeichen
  • Apostrophe
  • Datumsangaben
  • Et-Zeichen (&)
  • Fußnoten- und Anmerkungszeichen
  • Minus-Zeichen (-)
  • "bis"-Strich
  • "gegen"-Strich
  • Minus-Zeichen
  • Streckenstrich
  • Schreibung von Ziffern (Maße, Gewichte, Geldsorten)
  • Gliederung von Nummern
  • Telefonnummern
  • Fernschreibnummern (Telex)
  • (Postgiro-)Kontonummern
  • ISBN-Nummern
  • Gradzeichen
  • Paragraphzeichen
  • Prozent- und Promillezeichen
  • Rechenzeichen

2.1 Anforderungen

Es ist nun eine Form der Wissensrepräsentation mit einer geeigneten Darstellungsart zu entwickeln/finden, die es gestattet, alle oben angegebenen Konstrukte zu erkennen und gemäß den Satzanweisungen für den Schriftsatz aufzubereiten.

Das Expertenwissen für den Schriftsatz besteht demnach aus einer Menge von Regeln, die die Konstrukte gemäß den angegebenen Syntaxdiagrammen (s. Kap. 6.3) erkennen (parsen) und nach den Regeln für den Schriftsatz aufbereiten können. Die Problemlösungskomponente muß die Regelmenge auf einen gegebenen Text anwenden und ggf. dabei auftretende Inkonsistenzen/ Überschneidungen (s. Kap. 2.3) beheben: Die Problemlösung beinhaltet eine Analyse der Regelmenge (Richtlinien) auf derartige Inkonsistenzen mit einem entsprechenden Vorschlag, wie diese Inkonsistenzen zu beheben sind.

2.2 Probleme

Die bei der Lösung der gestellten Anforderungen auftauchenden Probleme lassen sich in folgende Punkte unterteilen:

  1. Als ein wesentliches Problem erweist sich das Vorhandensein von CR/LF-Paaren, da diese beim Parsen nicht berücksichtigt, aber andererseits auch nicht gelöscht werden dürfen. Durch das Überlesen des Zeilenendezeichens würde der Parsing-Vorgang wesentlich erleichtert. Da aber verschiedene Textarten, z.B. Briefe, Rechnungen und Auflistungen, einen Ausdruck im Flattersatz erzwingen (bestimmte Textteile stehen sonst nicht mehr untereinander), darf das Zeilenendesymbol nicht übergangen werden. Das bedeutet automatisch, daß sich die Pattern-Menge für jedes Konstrukt vergrößert und sich damit die Performance wesentlich verschlechtert.
  2. Eine Steigerung der Ineffizienz beim Parsing entsteht durch die Entdeckung von getrennt geschriebenen Schlüsselwörtern, also z.B. "10 Pro-zent" anstelle von "10 Prozent". Zu diesem Zweck ist es wiederum notwendig, die Zeilenendesymbole berücksichtigen zu können.
  3. Das nächste Problem tritt hauptsächlich bei einer bestimmten Form von Briefen, den Rechnungen, auf, bei welchen Unterführungszeichen verwendet werden können. Sollte dieser Text bei der späteren Textgestaltung anders formatiert werden, was normalerweise sehr wahrscheinlich ist, müssen diese durch den entsprechenden (unterführten) Text ersetzt werden. Das Auffinden der zugehörigen Worte erfordert das Vorhandensein der Zeilenendesymbole.
  4. Da das Et-Zeichen (&) nur bei Firmenbezeichnungen verwendet werden darf, aber nicht immer die Möglichkeit für eine derartige Identifizierung besteht ("Müller & Meier" bzw. "Müller & Co."), wird im Zweifelsfalle der Anwender gefragt werden müssen (Dialog).
  5. Ein weiteres Problem besteht in einer ausreichenden Unterscheidung zwischen Gedanken- und Bindestrichen in der Form, daß ein Gedankenstrich prinzipiell als ein eigenständiges Wort aufgefaßt werden kann.
  6. Das speziell bei der Textverarbeitung mit einem PROLOG-Interpreter auftauchende Problem ist das Einlesen bestimmter Zeichen, wie "." und "-" in Verbindung mit Zahlen. Diese Zeichen werden von einem PROLOG-Interpreter als zur Zahl zugehörig interpretiert und entsprechend eingelesen. Falls es sich um eine "normale" Zahl handelt, tritt kein Fehler auf. Handelt es sich aber um ein aus Ziffern zusammengesetztes Konstrukt, wie z.B. Datumsangaben oder Geldbeträge, so treten folgende Probleme auf:
    1. Bei Datumsangaben erhält man eine nicht einheitliche interne Darstellung, je nachdem, wie das Datum in dem betreffenden Text dargestellt ist ("01.01.1987" oder "1. 1. 1987"). Zum Beispiel wird das Datum "01.01.1987" als zwei Zahlen eingelesen, nämlich 1.01 und 0.1987. Diese beiden Zahlen sind aber nicht mehr ohne weiteres oder nur noch mit einem erhöhten Aufwand als eine Datumsangabe zu identifizieren. Das zweite Beispiel ("1. 1. 1987") wird sogar als drei Zahlen eingelesen: 1, 1 und 1987.
    2. Bei der Darstellung von Währungsbeträgen entstehen Probleme mit dem Dezimalpunkt, der in einem deutschsprachigen Text als "," (Komma) dargestellt wird. Der Dezimalbruch wird damit automatisch als eigene Zahl eingelesen, wodurch führende Nullen überlesen werden, d.h. beispielsweise, daß der Text "10,05 DM" als die vier Token "10", ",", "5" und "DM" eingelesen wird. Damit ist es nicht mehr möglich, zwischen einem ursprünglich falsch geschriebenen Text ("10,5 DM") und einer falschen Berechnung ("10,50 DM"), die mit Hilfe einer Angabe zur Stelligkeit des Dezimalbruchs durchgeführt werden kann, zu unterscheiden.
  7. Ein weiteres Problem ist die Verarbeitung spezieller Steuerzeichen (z.B. für den Unterstreichungs- oder Fettschreibmodus), wie sie in Textdokumenten kommerzieller Textverarbeitungsprogramme enthalten sind. Ein PROLOG-Interpreter kann nur normale ASCII-Dateien lesen, d.h. Dateien, die derartige Steuerzeichen nicht oder nur in einer stark vereinfachten Form enthalten.

2.3 Grammatiken

Die Erkennung bestimmter Konstrukte in einem Text ist durch den Einsatz geeigneter Grammatiken zu lösen, da Grammatiken zur Spezifikation von Sprachen und damit zur Definition erlaubter Zeichenfolgen (Syntax) verwendet werden. Zur Lösung der oben genannten Probleme sind darüber hinaus noch bestimmte Anforderungen an die Grammatik zu stellen, die letztendlich verwendet werden soll. Nachfolgend sind nun einige unterschiedliche Grammatikformen angeführt. Für weitergehende Informationen sei an dieser Stelle auf die entsprechende Fachliteratur verwiesen.

2.3.1 Transition Networks

Der erste hier kurz erläuterte Grammatiktyp ist das Übergangsnetzwerk<$SÜbergangsnetzwerk;Transition Network>, von dem es zwei verschiedene Arten gibt:

die Recursive Transition Networks (RTNs) und

die Augmented Transition Networks (ATNs).

Ein RTN ist im wesentlichen ein Netzwerk von Knoten und Kanten. Die Knoten repräsentieren den Zustand, der momentan beim Parsen eines Satzes erreicht worden ist. Im Gegensatz dazu spezifizieren die Kanten die möglichen Übergänge (Transitions) von einem Zustand zu einem anderen, die durch das Parsen eines Wortes oder einer Phrase herbeigeführt werden können.

Die Zustände selbst können wiederum in Ebenen, die einzelnen Parsern für die unterschiedlichen Phrasen entsprechen, eingeteilt werden. Eine Ebene besteht aus einem Netzwerk mit einem Startknoten und einem oder mehreren Endzuständen. Ein Knoten kann dazu dienen, rekursiv - daher der Name - eine Ebene tiefer zu gehen, eine ganze Struktur einzulesen und dann auf die ursprüngliche Ebene zurückzukehren.

Ein ATN ist ein RTN, das um eine Menge von Registern erweitert wurde. Diese Register können durch Aktionen, die an den Kanten stehen, beim Übergang von einem Zustand zum nächsten mit Werten gefüllt werden. Die Werte dieser Register können dann durch Bedingungen, die ebenfalls an den Kanten stehen, getestet werden, um das Durchlaufen bestimmter Übergänge und Zustände zu steuern. Beispielsweise kann das Geschlecht und die Zahl des Subjektes und des Prädikats gespeichert werden, um später deren Übereinstimmung zu überprüfen, oder ganze Phrasen, um sogenannte Long-Distance-Dependencies aufzulösen. Die möglichen Werte dieser Register können deshalb einzelne Attribute der Phrasen oder auch ganze Phrasenstrukturen sein. Auf diese Weise ist es bspw. möglich, Tiefenstrukturen á la Chomsky - also die Auflösung von Passivkonstruktionen - zu erzeugen.

Abb. 2.1: ATN-Grammatik

Ein wichtiger Vorteil von ATNs gegenüber anderen Grammatikformen ist die Fähigkeit, die Kanten vor- und rückwärts zu durchlaufen, um den Typ der Konstituenten vorherzusagen und damit die Möglichkeiten einzuschränken. Formal entsprechen die ATNs den endlichen Automaten, Push-Down-Automaten und Turingmaschinen. Von daher ist ein ATN ein Automat, der sich die Position in der Eingabezeichenkette, den Knoten, die Werte seiner Register und den Stack, der durch die rekursiven Durchläufe durch die einzelnen Graphen aufgebaut wird, merkt.

2.3.2 Case Grammmar

Es gibt mehrere Arten von "Case-Grammatiken", die alle ähnliche Konzepte verfolgen. Ursprünglich dienten sie dazu, Substantive anhand ihrer Beugungen gemäß ihrer syntaktischen Rolle innerhalb eines Satzes zu klassifizieren: den "Surface" oder "Syntactic Level". Diese Art der Klassifizierung reicht aber in den meisten Fällen nicht aus. Zusammen mit lexikalischen und morphologischen Informationen läßt sich die semantische Rolle bestimmen, die ein Substantiv in einem Satz spielt.

Ein anderes Verständnis von "Case" ist die Unterteilung von Substantiven gemäß ihrer konzeptionellen Rolle in der innerhalb des Satzes beschriebenen Aktion: "Deep Case", "Semantic Case" oder auch "Theta Role" genannt. Zum Beispiel ist der "Agent Case" eine Abstraktion von "dem Leser", "dem Spaziergänger", "dem Fußballspieler" usw. Weil diese konzeptionellen Rollen die Bedeutung der Wörter beschreiben sollen, sind sie sprachunabhängig. Eine Menge von Cases wird auch Case System genannt, von denen die vier wichtigsten von Fillemore, Celce, Grimes und Shank stammen.

Abb. 2.2: Case-Grammatik

Um den Parsingvorgang zu erleichtern, d.h. Zweideutigkeiten aufzulösen, kann den einzelnen Konstituenten ein sog. "Case Frame" zugeordnet werden, in dem alle wichtigen Eigenschaften beschrieben werden. So könnte ein Case Frame für 'kicking' folgendermaßen aussehen:

[{agent}: animate object,
object: physical object,
{instrument}: physical object,
{source}: location,
{goal}: location].

(Die Elemente in geschweiften Klammern sind optional.)

Nach Fillmore besteht ein Satz aus einer Modalität mit Negationen, Zeitangaben und ähnlichem, einer Struktur aus einem Verb ohne Zeitangabe und mindestens einem Case. Ein Case wiederum besteht aus einem sprachabhängigen Kasuselement und einem Substantiv oder einem geschachtelten Nebensatz. Diese Art der Darstellung ermöglicht die Abbildung von Tiefenstrukturen in Oberflächenstrukturen.

Fillmore hat mehrere Case Systeme entwickelt, die jeweils unterschiedlichen Aspekten der Bedeutung verschiedener Worte Rechnung tragen. Deshalb sei hier ein Auszug aus einem Case System von Fillmore angegeben:

Agent(A) The instigator of the event
Counter Agent(C) The force or resistance againts which the action is carried out
Object(O) The entity that moves or changes or whose position or existence is in consideration
Result(R) The entity that comes into existence as a result of the action
Instrument(I) The stimulus or immediate physical cause of an event
Source(S) The place from which something moves
Goal(G) The place to which something moves
Experience(E) The entity that receives or accepts or experiences or undergoes the effect of an action

Shank orientiert sich bei seinem Case System mehr an der Aufgabenstellung, die die Sprache für den Menschen hat. So führt er eine kleine Anzahl primitiver Aktionen ein, die in den meisten Fällen für die Beschreibung von Events ausreichen und die von einer bestimmten Struktur von Aktionen ausgehen:

Actors perform actions.
Actions have objects.
Actions have instruments.
Actions may have recipients.
Actions may have directions.

Die primitiven Aktionen sind dabei von der Art "transfer a physical object" oder "transfer mental information".

2.3.3 Definite-Clause Grammar

Warren und Pereira haben 1978 die Idee dieser Grammatikform, die auf Hornklauseln basiert, eingeführt. Definite-Clause Grammatiken sind eine Erweiterung von kontextfreien Grammatiken, die sehr leicht in Form von Produktionsregeln in PROLOG unter Hinzunahme von zusätzlichen Parametern zur Variablenübergabe implementiert werden können:

sentence --> noun-phrase verb-phrase

Die Bedeutung eines Satzes wird so in eine logische Struktur überführt, die zwecks weiterer Verarbeitung leicht zu handhaben ist. Beispielsweise wird der Satz

Chomsky writes a book

in der folgenden Struktur dargestellt:

for a

B

such that

B is (a) book

it is true that

Chomsky writes B

2.3.4 Generalized Phrase Structure Grammar

Diese Grammatikform ist ebenfalls eine Variante von kontextfreien Grammatiken, die syntaktische Kategorien anhand von Eigenschaftsspezifikationen aufstellt. Eine derartige Kategorie ist eine partielle Funktion, die Eigenschaften auf die möglichen Werte abbildet. Darüber hinaus können diese Kategorien durch zusätzliche Bedingungen, wie Dominanz-, Reihenfolge-, Kombinations- und Instanziierungsregeln, weiter eingeschränkt werden.

2.3.5 Phrase-Structure Grammar

Phrasenstrukturgrammatiken stellen strukturierte Beschreibungen eines Satzes bereit, die durch Bäume oder Klammerstrukturen dargestellt werden können.

Abb. 2.3: Phrasen-Struktur-Grammatik

Wie jede Grammatik enthält eine Phrasenstrukturgrammatik Nichtterminalsymbole, die durch Grammatikregeln nach und nach durch Terminalsymbole, das sind die einzelnen Worte, ersetzt werden. Die Ableitung beginnt dabei wie üblich mit der Ausdehnung des Nichtterminalsymbols "S", das für die gesamte Satzstruktur steht:

S --> NP VP
NP --> NPR
NP --> DET N
P --> V VP
VP --> P V NP

NPR --> John, Mary, Bill
N --> paper, man, cow
V --> wanted, tried, publish, meet, published, want
P --> to
DET --> the

Um die Anzahl der möglichen Worte zu reduzieren und Redundanzen zu vermeiden, werden die Terminalsymbole zu Strukturen zusammengefaßt, die phonologische, syntaktische und semantische Eigenschaften beschreiben.

2.3.6 Semantic Grammar

In semantischen Grammatiken beziehen sich die Kategorien sowohl auf semantische als auch auf syntaktische Konzepte.

Der Unterschied zu anderen Grammatiken besteht nur in der Art der Informationen und nicht darin, wie diese gespeichert werden. So kann dazu eine andere der hier genannten Grammatikformalismen genutzt werden.

Das Ziel semantischer Grammatiken ist die Interaktion mit dem Benutzer. Die Grammatiken werden dann zum Aufbau von natürlichsprachlichen Zugangssystemen benutzt. Deshalb hängt die Auswahl der benötigten Kategorien von der Intention ab, die der Benutzer mit dieser Grammatik verfolgt. Dies kann am besten am folgenden Beispiel verdeutlicht werden:

Abb. 2.4: semantische Grammatik (Teil 1)

Abb. 2.5: semantische Grammatik (Teil 2)

So kann eine Frage bspw. durch folgende Regel angegeben werden:

<Query> ::= <Question-Intro> <Measurement>

Ein besonders Problem beim Verstehen natürlicher Sprache ist das Verfolgen eines Diskurses. Darunter ist das Verstehen und Beantworten von Fragen gemeint, die nacheinander gestellt werden und dabei evtl. nicht vollständig sind: Ellipsen.

Bei semantischen Grammatiken wird dieses Problem durch Ausnutzen ähnlicher Strukturen, die bei vorhergehenden Sätzen aufgebaut worden sind, gelöst. Dabei werden die spezifischen Kategorien der jeweiligen semantischen Grammatiken substituiert.

Semantische Grammatiken haben aber auch einige Schwächen:

geschachtelte Strukturen bereiten Probleme

sie sind abhängig von der Domäne, die die Sätze abdecken sollen

Um die Vorteile von semantischen Grammatiken ausnutzen zu können, werden diese häufig mit anderen Grammatikformalismen kombiniert.

2.4 Der benutzte Grammatikformalismus

Der hier definierte Formalismus orientiert sich dabei sehr stark an den ATN-Grammatiken, die mit ihren Registern am ehesten in der Lage sind, die Anforderungen, die an den genutzten Grammatikformalismus gestellt werden müssen, zu erfüllen. Die Fähigkeit der Grammatik, die zu analysierende Struktur sowohl vorwärts als auch rückwärts auszuwerten, kommt ihr zugute.

Die einzelnen Diagramme sind so aufgebaut, daß möglichst große Bereiche von verschiedenen Schreibweisen für ein Konstrukt noch als ein solches erkannt wird. Besonders wichtig ist die Tatsache, daß an beliebigen Stellen innerhalb eines Textes beliebig viele Leerstellen und Carriage Return/Line Feed-Paare (im folgenden CR/LF-Paar genannt) stehen können. Die normale BNF-Form für Syntaxdiagramme ist darüber hinaus noch um spezielle Eigenschaften erweitert worden:

1. Nach einem langen, einfachem Pfeil ("-->") folgt eine Angabe mit (Nicht-)Terminalsymbolen, die das zurückzuschreibende Konstrukt angibt. Sollten dabei neue Nichtterminalsymbole verwendet werden, so wird deren Inhalt anschließend in geschweiften Klammern ("{" und "}") näher spezifiziert. Die Spezifikation erfolgt in der Form, daß links von einem Zuweisungspfeil ("<=") das Nichtterminalsymbol und rechts davon eine Funktion, die dann beliebig umfangreich sein kann, zur Berechnung des Wertes mit den benötigten Parametern steht. Sollte kein einfacher Pfeil mit einem entsprechenden zurückzuschreibenden Konstrukt vorhanden sein, so wird des geparste Konstrukt selber zurückgeschrieben.

2. In den geschweiften Klammern kann mittels des Zuweisungspfeils einer globalen Variable eine bestimmte Konstante zugewiesen werden, die dann in einem anderen Teil des Parsing-Baumes als Funktionsparameter weiterverwendet (abgefragt) werden kann. Dadurch ist es möglich, daß umfangreiche Umformungen und Vereinheitlichungen durchgeführt werden können. Eine Standardvariable ist "BEN". Sie enthält benutzerspezifische, nicht näher erläuterte Angaben, die zu Beginn des Programmlaufes abgefragt werden und dann immer zur Verfügung stehen.

3. Normalerweise gibt es verschiedene Möglichkeiten, einen Lösungsbaum beim Parsing-Vorgang aufzubauen, weil die BNF-Grammatiken an beliebiger Stelle ein Nichtterminalsymbol expandieren können. Aus Effizienzgründen sollte allerdings bei manchen Syntaxdiagrammen der Parsing-Vorgang mit einem bestimmten Symbol begonnen werden und deshalb ist dieses durch Unterstreichung besonders gekennzeichnet. Bei diesem Symbol handelt es sich nicht unbedingt um ein Nichtterminalsymbol, sondern meistens um ein Kennzeichen, das zu Beginn des Parsing-Prozesses herausgesucht wurde. Sollte dieses Symbol schon nicht einwandfrei geparst werden können, so kann der Parsing-Prozeß für dieses Konstrukt abgebrochen und mit dem nächsten Kennzeichen, falls es existiert, an einer anderen Textstelle oder dem nächsten Syntaxdiagramm fortgefahren werden.

4. Nicht explizit angegebene Produktionsregeln sind in den vorhergehenden Diagrammen schon einmal angegeben worden und dann von dort zu übernehmen.

Beispiel für ein Syntaxdiagramm:

<xy> ::= <x> <y>

--> "Anfang: " <x'> <y'> { <x'> <= f1(<x>), <y'> <= f2(<y>) }
| <z1>
| <z2>
--> <z2'> { <z2'> <= <z2> <z2> }

Dieses Beispielkonstrukt <xy> kann folgende Zeichen parsen:

1.) <x> <y>

2.) <z1>

3.) <z2>

Nach dem Parsing-Vorgang werden dann die folgenden Zeichenketten zurückgeschrieben:

für 1.) "Anfang: " <x'> <y'>
d.h. "Anfang: " konkateniert mit f1(<x>) und f2(<y>)

für 2.) <z1>

für 3.) <z2> <z2>

Die formale Beschreibung in BNF-Form für die folgenden Syntaxdiagramme lautet:

<GRUNDFORM> ::= <LINKER-TEIL> "::=" <RECHTER-TEIL> [<RECHTE-TEILE>]

<RECHTE-TEILE> ::= "|" <RECHTER-TEIL> [<RECHTE-TEILE>]

<LINKER-TEIL> ::= <NICHTTERMINALSYMBOL>

<RECHTER-TEIL> ::= <SYMBOLE> [">" <SYMBOLE> ["{" <UMSETZUNGEN> "}"]]

<SYMBOLE> ::= <SYMBOLE> <SYMBOLE>
 | <SYMBOL>
 | "[" <SYMBOLE> "]"

<SYMBOL> ::= <NICHTTERMINALSYMBOL>
 | <TERMINALSYMBOL>

<NICHTTERMINALSYMBOL> ::= "<" KONSTANTE ">"

<TERMINALSYMBOL> ::= KONSTANTE

<UMSETZUNGEN> ::= <UMSETZUNG> ["," <UMSETZUNGEN>]

<UMSETZUNG> ::= <NICHTTERMINALSYMBOL> "<=" <FUNKTION>
 | <VARIABLE> "<=" <WERT>

<FUNKTION> ::= "f" <INDEX> "(" <PARAMETER> ")"

<INDEX> ::= <KONSTANTE>

<PARAMETER> ::= <PARAMETER> ["," <PARAMETER>]
 | "BEN"
 | <VARIABLE>
 | <NICHTTERMINALSYMBOL>
 | <TERMINALSYMBOL>

<VARIABLE> ::= <KONSTANTE>

<WERT> ::= <KONSTANTE>

<KONSTANTE> ::= <BEL. ZEICHEN> [<KONSTANTE>]

<BEL. ZEICHEN> ::= "a" | "b" | .. | "z"
  | "A" | "B" | .. | "Z"
  | "0" | "1" | .. | "9"
  | ..

Worttrenner:

<trenner> ::= [<trenner1>] [CR/LF] <trenner1>
 | [<trenner1>] CR/LF [<trenner1>]

<trenner1> ::= " " [<trenner1>]

Ein Worttrenner ist eine beliebig lange, nichtleere Zeichenkette aus beliebig vielen Leerstellen und maximal einem CR/LF-Paar.

Im Anhang sind die Syntaxdiagramme für die einzelnen Konstrukte ausführlich mit entsprechenden Anmerkungen angegeben. Nachfolgend sollen nur an einem Ausschnitt die Möglichkeiten verdeutlicht werden.

<geld> ::= <betrag> <einheit>
--> <ergebnis>
{<ergebnis> <= f
reihenfolge(<einheit>, <betrag>, BEN)}
 | <einheit> <betrag>
--> <ergebnis>
{<ergebnis> <= f
reihenfolge(<einheit>, <betrag>, BEN)}

<geld-bereich> ::= <geld> "-" <geld>

2.5 Bemerkungen zur Implementierung

Um die oben genannten Probleme überschaubar zu machen, wurden folgende Überlegungen angestellt:

2.5.1 Problemlösung

Die Lösung der Probleme gliedert sich in die folgenden Teillösungen:

1. Lösung der gestellten Anforderungen

2. Lösung der allgemeinen Probleme

3. Lösung der vom PROLOG-Interpreter abhängigen Probleme

2.5.1.1 Lösung der gestellten Anforderungen

Die vom Programmieraufwand her für die gestellten Anforderungen einfachste Lösung bestünde darin, ein einziges Syntaxdiagramm anzugeben, das alle Konstrukte identifizieren und korrekt nach den Satzanweisungen umsetzen kann. Dieses Syntaxdiagramm ließe sich zwar konstruieren; es wäre aber sehr ineffizient, damit zu arbeiten: Die verschiedenen Kennzeichen würden innerhalb dieses Diagramms mehrmals erscheinen, und es ließe sich nur durch ein Mehrfaches des erforderlichen Rechenaufwandes herausfinden, welche semantische und syntaktische Bedeutung dieses Kennzeichen gerade hat.

Ein Ausschnitt des Diagramms müßte demnach so aussehen:

Abb. 2.5: übergeordnetes Syntaxdiagramm
(von links nach rechts zu lesen)

In diesem vereinfachten, übergeordneten Syntaxdiagramm stellt der Teil mit den einfachen durchgehenden Linien ein Teil des Syntaxdiagramms für eine Datumsangabe und der Teil mit den punktierten Linien den Teil für ein Satzende dar. Der Punkt, der in beiden Teilen auftaucht, kann nicht nur einmal dargestellt werden, da das Diagramm dann nicht mehr eindeutig und korrekt wäre. Ob nun ein bestimmter Teil des Syntaxdiagramms als zu einem Konstrukt gehörig geparst werden darf, kann nur entschieden werden, wenn eine bestimmte Anzahl von Zeichen (Wörtern) im voraus gelesen werden ("Look-ahead"). Dies wird durch die gestrichelte Linie (".") deutlich, die den ersten (linken) Teil der punktierten Linie ("-.-") ersetzen müßte: In diesem Falle ließe sich als Datumsangabe auch der ". November" herleiten, welches aber eine nicht zulässige Angabe ist.

Wenn dieses Syntaxdiagramm schon so aufgebaut ist, daß die einzelnen Kennzeichen mehrfach vorkommen, kann dieses Diagramm auch ohne Schwierigkeiten in mehrere kontextfreie Einzelgrammatiken (s. Kap. 6.3) zerlegt werden, so daß diese dann in einer bestimmten Reihenfolge durch höherspezialisierte Parser abgearbeitet werden können. Dies wird durch die Tatsache, daß bestimmte Kennzeichen, wie z.B. ".", "," und Zahlen, schon mit Angabe der Wortnummer als PROLOG-Fakten (s. Kap. 3.3.9: Struktur des Textspeichers) vorhanden sind, sehr vereinfacht.

Die auftretende Problematik der gegenseitigen Beeinflussung muß allerdings behoben werden: Das kann aber nur dadurch geschehen, daß die Syntaxdiagramme auf Überschneidungen durchsucht werden. Eine Überschneidung tritt auf, wenn eine Instanz eines Syntaxdiagramms für ein Konstrukt auch eine Instanz eines Syntaxdiagramms eines anderen Kontruktes enthalten kann:

Bsp.: "Der 5. Juli 1987 war ein schöner Tag."	
^: Satzanfang (großgeschriebenes Wort)
^: Trennzeichen (" ")
^: Satzzeichen (".")

Ein Satzende ist durch ein entsprechendes Symbol, gefolgt von einem großgeschriebenen Wort, gekennzeichnet. Wenn ein groß geschriebenes Wort als eine Buchstabenfolge, die mit einem Großbuchstaben beginnt, definiert wird, entstehen Probleme mit der Darstellung von Datumsangaben: z.B. 5. Juli 1987. Das heißt, daß diese Datumsangabe durch eine solche Regel als Satzende erkannt würde. Definiert man ein groß geschriebenes Wort durch einen Großbuchstaben, der von einer beliebigen Buchstabenfolge gefolgt sein kann, so bekommt man Probleme mit der Erkennung von Abkürzungen.

Abhilfe:

In unserem Beispiel muß für einen Satzende-Test bekannt sein, daß kein Datum vorliegt. Damit dieses Wissen beim Satzende-Test vorhanden ist, muß der Datumsangabe-Test vorher ausgeführt worden sein. Mit dem Test auf Datumsangaben sollten auch die Tests auf Abkürzungen vor dem Satzende-Test durchgeführt werden. Dann ist es auch möglich, den Punkt als Satzende vor dem englischen Wort "a" am Satzanfang ("A") korrekt zu identifizieren. Da alle wichtigen noch nicht abgearbeiteten Kennzeichen in einer separaten Tabelle gespeichert werden, sollten alle, sobald sie einem Konstrukt zugeordnet werden können, daraus gelöscht werden. Das führt dann dazu, daß in unserem Beispiel für einen Satzende-Test nur noch die Kennzeichen zur Verfügung stehen, bei denen es sich nicht um eine Datumsangabe handelt. Damit ist außerdem eine doppelte Zuordnung ausgeschlossen, was sich nebenbei als eine Effizienzsteigerung bemerkbar macht.

Alle vorhandenen Syntaxdiagramme müssen auf derartige Überschneidungen untersucht werden, um eine Halbordnung für eine Regelanwendungsreihenfolge zu erhalten. Es genügt für eine Reihenfolgevorschrift schon, beispielhaft zu zeigen, daß ein untergeordnetes Syntaxdiagramm auf eine Instanz des übergeordneten Syntaxdiagramms anwendbar ist.

Nach einer näheren Untersuchung erhält man folgende transitive Reihenfolgerelation:

  • Datumsangaben vor Abkürzungen (abh. v. Tabelleneinträgen)
  • Datumsangaben vor Rechenzeichen (engl. Darstellung)
  • Abkürzungen vor Satzenden
  • Rechenzeichen vor Minuszeichen
  • Rechenzeichen vor Gedankenstrich
  • Währungen vor Minuszeichen
  • Währungen vor Gedankenstrich
  • Bis-Strich vor Minuszeichen
  • Bis-Strich vor Gedankenstrich
  • Prozent-/Promillezeichen vor Zahlen
  • Paragraphzeichen vor Zahlen
  • Minuszeichen vor Zahlen
  • Gedankenstrich vor Zahlen

Nach Untersuchung der Verteilung der Zeilenendesymbole müssen die Unterführungszeichen mit den zugeordneten (unterführten) Worten gekennzeichnet werden, da eine derartige Zuordnung nach der Löschung dieser Symbole nicht mehr möglich ist. Eine Löschung kann aber nicht umgangen werden, da evtl. getrennt geschriebene Kennworte (z.B. "Pro-zent", s. auch Kap. 2.2, Pkt. 2) sonst nicht erkannt werden können und somit eine korrekte Darstellung nicht gegeben ist.

Diese Tatsache führt zusätzlich zu folgender Reihenfolge:

  • Erst die Kennzeichen suchen, dann die Unterführungszeichen auffinden und ersetzen und danach die Zeilenenden löschen,
  • die Trennungen ebenfalls aufheben bevor die Zeilenenden gelöscht werden und
  • die Zeilenenden löschen und dann den Parsing-Prozeß beginnen.

Eine graphische Repräsentation dieser Reihenfolgerelation ließe sich folgendermaßen darstellen:

Abb. 2.6: Reihenfolgerelation
(höherliegende Einträge sind vor den darunterliegenden, verbundenen Einträgen zu testen)

2.5.1.2 Lösung der allgemeinen Probleme

Verschiedene Konstrukte (s. Kap. 2.2, Pkt. 4) können nur richtig erkannt werden, wenn diese als Tabelleneinträge vorliegen oder aber im Dialog eingelesen werden. Bei den Gedanken-, Binde- und Trennstrichen (s. Kap. 2.2, Pkt. 5) kann nur eine ausreichende Unterscheidung getroffen werden, wenn diese korrekt geschrieben worden sind. Ein Gedankenstrich muß prinzipiell als ein eigenständiges Wort aufgefaßt werden, d.h. es muß mit Trennzeichen eingerahmt werden, im Gegensatz zu Trennstrichen, die an ein Wort angehängt werden, und Bindestrichen, die zwischen zwei Wörtern stehen.

Spezielle Steuerzeichen (s. Kap. 2.2, Pkt. 7) dürfen nicht verwendet werden, da diese von einem PROLOG-Interpreter nicht eingelesen werden können. Um dennoch eine ausreichende Funktionalität zu gewährleisten, können jedoch stark vereinfachte Steuerzeichen (z.B.: "FETT_EIN" und "FETT_AUS"), die mit einer sehr großen Wahrscheinlichkeit innerhalb eines normalen Textes nicht vorkommen, verwendet werden.

2.5.1.3 Lösung der vom PROLOG-Interpreter abhängigen Probleme

Der verwendete PROLOG-Interpreter gestattet es, einzelne Terme in einem bestimmten Format (String, Charakterliste, binär, Zahlen) einzulesen. Dadurch und durch die Möglichkeit, den File-Pointer frei in einer Datei zu positionieren, kann jede beliebige Textstelle in der Datei eingelesen werden. Zusammen mit der Positionsangabe des Wortes innerhalb der Datei kann die fragliche Textstelle noch einmal als Charakterliste, die einer entsprechenden Nachbearbeitung unterzogen wird, gelesen werden. Durch diese Möglichkeit des freien Dateizugriffs lassen sich folgende Probleme lösen:

  1. das Einlesen bestimmter Zeichen im Zusammenhang mit Zahlen (s. Kap. 2.2, Pkt. 6),
  2. das "Überlesen" von CR/LF-Paaren (s. Kap. 2.2, Pkt. 1) und
  3. das Ersetzen von Unterführungszeichen (s. Kap. 2.2, Pkt. 3).

2.5.1.4 Erklärungskomponente für den Schriftsatz

Eine direkt kontextabhängige Erklärungskomponente für den Schriftsatz existiert nicht, weil die vorhandenen Parser nur dann eine Eingabemöglichkeit vorsehen, wenn es für eine Aufbereitung mehrere Möglichkeiten gibt. Die Erklärung kann demnach nur aus einem vorgefertigten Text bestehen, der auf dem Bildschirm ausgegeben wird und erläutert, nach welchen Regeln die einzelnen Konstrukte geparst und dann zurückgeschrieben werden.

2.5.2 Wissensrepräsentation für den Schriftsatz

Die Repräsentation des Wissens für den Schriftsatz befaßt sich mit der Repräsentation des Textes und der Regeln, nach denen der Text abgearbeitet wird.

2.5.2.1 Repräsentation der Regeln

Es ist empfehlenswert, die Regeln nicht in einer BNF-Form für einen allgemeinen Parser abzuspeichern: Dadurch, daß die Regelmenge für die erkennbaren Konstrukte wesentlich größer ist als die Regelmenge der auszugebenden Konstrukte, muß die normale BNF-Form noch um eine Repräsentation für die Vorher-nachher-Umsetzung erweitert werden. Da diese Umsetzung aber nicht unbedingt einheitlich gestaltet werden kann, das betrifft z.B. die Umsetzung für die Abkürzungen, ist es auch nicht ohne weiteres möglich, einen universellen Parser dafür zu entwickeln. Dieser universelle Parser müßte u.a. die Semantik berücksichtigen, die in den jeweiligen Konstrukten enthalten ist, beispielsweise in den Datumsangaben.

Es ist besser, für jedes Konstrukt einen spezialisierten und höherwertigen Parser zu entwickeln, der bei der Textverarbeitung zusätzlich noch weiterführende Aufgaben, wie z.B. eine Überführung in eine normierte Darstellungsart, übernehmen kann und eine Semantik implizit enthält. Eine Möglichkeit, den Parsing-Prozeß zu verbessern, besteht darin, nicht nur nach rechts abzuleiten (zu erweitern), wie es durch ein einmaliges Lesen des Textes geschehen würde, sondern auch nach links: Durch dieses Vorgehen kann die bereits erstellte Tabelle mit den besonderen Kennzeichen ausgenutzt werden.

2.5.2.2 Repräsentation des Textes

Die Repräsentation des Textes kann in PROLOG grundsätzlich auf drei Arten erfolgen:

  1. als Liste,
  2. als Baum,
  3. als Fakten/Tupel.

Die Darstellung als Liste scheidet als Möglichkeit sofort aus, da ein effizienter Zugriff auf die einzelnen Wörter gar nicht erreicht werden kann. Durch eine hohe Rekursionstiefe tritt zudem eine große Speicherauslastung auf, die keine intensiven Berechnungen ermöglicht.

Ein Baum würde zwar einen direkten Zugriff prinzipiell erlauben, sofern keine indirekte Darstellung in Listenform gewählt wird; dieser ließe sich aber wiederum in PROLOG nur sehr ineffizient realisieren.

Bleibt nur die dritte Möglichkeit der Repräsentation als Tabelle: In dieser Tabelle werden dann alle Wörter als Tupel abgespeichert. Ein Tupel könnte dabei aus folgenden Objekten bestehen:

  1. dem Wort selber,
  2. der Nummer des Wortes (inkrementelle Numerierung beim Einlesen),
  3. der Anfangsposition des Wortes in der Datei,
  4. einem Kennzeichen dafür, ob es sich bei dem Wort um ein Kennwort handelt,
  5. einem Kennzeichen dafür, als welches Konstrukt das Wort erkannt wurde.

Eine Tupeldarstellung ist aus Gründen der einfacheren Implementierung, der leichteren Durchschaubarkeit und Formulierung der Regeln empfehlenswert.

Eine Repräsentierung als Quintupel ist aus folgenden Gründen aber nicht zu empfehlen:

  1. Die Aufnahme eines Kennzeichens dafür, ob es sich bei diesem Wort um ein Kennwort handelt, würde nicht die erwünschte Effizienzsteigerung erzielen, da zum Auffinden bestimmter Kennworte trotz dieser Markierung alle Einträge (über den Unifikationsprozeß) durchsucht werden müssen. Diese Effizienzsteigerung wird dann erreicht, wenn eine getrennte Tabelle mit Paaren aus der Wortnummer und diesem Kennzeichen, falls eines existiert, eingerichtet wird. Dann besteht auch eine einfache Möglichkeit, dieses Kennzeichen getrennt vom Wort zu löschen.
  2. Da es sich in der Regel bei der Mehrheit der Wörter nicht jeweils um ein besonderes Konstrukt handelt, lohnt es sich nicht, ein Kennzeichen dafür direkt in diese Relation aufzunehmen. Einfacher und auf zukünftige Erweiterungen ausgerichtet ist ebenfalls eine Repräsentierung als eigene Tabelle mit einem entsprechenden Verweis auf das zugehörige Wort (über die Wortnummer).
  3. Die Anfangsposition des Wortes muß als Eintrag vorhanden sein, damit Zahlen noch mal eingelesen werden können, da sonst bei der weiteren Verarbeitung die o.g. Probleme auftreten können.

Nach diesen Überlegungen erscheint die folgende Repräsentierung aus mehreren Tupeln sinnvoll:

worte (Wort-Nr, Datei-Pos, Wort).

kennzeichen (Code, Wort-Nr).

erkannt (Erkannt-als, Wort-Nr [, Option]).

Eine Repräsentierung als Tupel hat den Vorteil, daß ein direkter Zugriff auf die "Nachbarworte" möglich ist.

Nach einer erfolgreichen Abarbeitung der Wörter nach den Regeln den Schriftsatzes können die Wörter in eine neue Tabelle übertragen werden, die dann etwas anders aufgebaut ist:

worte2 (Wort-Nr, Wortlänge, Wort).

und

stellen2 (Wort-Nr, Erkannt-als).

Bei dieser Übertragung werden die Worte neu durchnumeriert und ihre Länge berechnet, damit der Algorithmus zur Verteilung der Zeilenenden effizienter arbeiten kann (s. Kap. 3.3.6). Außerdem wird die Position des Wortes in der Datei zur weiteren Verarbeitung nicht mehr benötigt.

Die erkannten Konstrukte werden mit der neuen Wortnummer in einer zweiten Tabelle ("stellen2") abgespeichert.

Bei der Silbentrennung und Verteilung der Zeilenenden können ebenfalls entsprechende Attribute an die betroffenen Tupel angehängt werden, die bei einer Neuformatierung dann einfach ge"kill"ed werden können:

zeilenende (Wort-Nr, Zeilen-Nr).

zeilenanfang (Wort-Nr, Zeilen-Nr).

zwischenraumbreite (Zeilen-Nr, Breite).

getrennt-als (Wort-Nr, Teilwort1, Teilwort2).

2.5.2.3 Repräsentation anderer Daten

Neben der Repräsentation des Textes müssen für andere Tabellen auch entsprechende Repräsentierungen gewählt werden. Das gilt z.B. für folgende Fakten:

  1. Abkürzungen,
  2. Firmennamen,
  3. Trennungen,
  4. Apostrophe.

Zu 1.: Zur Repräsentation der Abkürzungseinträge sind folgende Eigenschaften notwendig: (s. auch Kap. 6.3.4)

1.1 Die zu ersetzenden Abkürzungen müssen als Liste von Worten repräsentiert sein, damit diese genau mit der Reihenfolge der Worte in dem Text verglichen werden können.

1.2 Es muß ein Kennzeichen vorhanden sein, wie die entdeckten Abkürzungen zu behandeln sind: Sie werden immer durch den Ersatztext ersetzt, oder sie werden einer speziellen Prüfung unterzogen.

1.3 Der Ersatztext für die entdeckten Abkürzungen: Er kann als ein String ausgebildet sein, besser ist aber eine Implementierung als Liste von entsprechenden Wörtern, damit diese dann auch als eigenständige Wörter behandelt werden können.

Zu 2.: Die Repräsentation der Einträge für die Firmennamen kann ähnlich der für die Abkürzungen gehalten werden: (s. Kap. 6.3.14)

2.1 Die zu ersetzenden Teile des Firmennamens müssen als Wortliste repräsentiert sein, damit diese genau mit der Reihenfolge der Worte in dem Text verglichen werden können.

2.2 Der Ersatztext für den Firmennamen kann ebenfalls als Liste von Worten implementiert werden.

Zu 3.: Ein Eintrag muß eine Liste von Worten enthalten, die nach einem Wort mit einem Trennstrich stehen müssen, damit eine Trennung nicht aufgehoben zu werden braucht. (s. Kap. 6.3.7)

Zu 4.: Diese Einträge geben die Ausnahmen an, d.h., wenn dem Apostroph kein regelmäßiger Wortzwischenraum vorausgeht. (/Duden DT5/, S. 46; s. Kap. 6.3.16)

2.5.3 Optimierungen

Um die grundlegenden Probleme des Einlesens von Objekten zu umgehen, wird ein Präprozessor vor den eigentlichen Einlesevorgang vorgeschaltet, der bestimmte Kennzeichen, wie z.B. ".", ",", "-" und verschiedene Satzzeichen, unter bestimmten Bedingungen isoliert, d.h. in Leerzeichen einbettet oder in bestimmte Kennwörter übersetzt. Auf diese Weise werden die Zahlen und einzelnen Satzzeichen einzeln eingelesen.

Des weiteren besteht die Möglichkeit, die Performance noch auf andere Arten zu erhöhen:

  1. Da einzelne Regelmengen nicht in einer Abhängigkeitsrelation stehen, können diese bei bestimmten Textarten ausgelassen werden, da sie zu selten vorkommen. Das ist z.B. der Fall bei Prozent- und Paragraphzeichen innerhalb von Romanen.
  2. Durch eine andere Reihenfolge der Regeln, die auf dieselben Kennzeichen zugreifen, ist es nicht mehr nötig, die verbleibenden Kennzeichen mehrmals zu parsen. Es gibt zwei Möglichkeiten, den Text abzuarbeiten: 1. Der Absatz wird nach verschiedenen Konstrukten nacheinander durchsucht, oder 2., sobald ein Kennzeichen gefunden worden ist, werden die einzelnen Syntaxdiagramme durchgegangen, bis dieses Kennzeichen einem bestimmten Konstrukt zugeordnet werden kann. Der Vorteil dieser Effizienzsteigerung wird allerdings mit einer nicht mehr so leicht zu durchschauenden Regelmenge erkauft.
  3. Eine absatzweise Verarbeitung gestattet es, nicht mehr alle Kennzeichen miteinander vergleichen zu müssen, sondern nur noch diejenigen, die in demselben Absatz stehen. Ein positiver Nebeneffekt besteht darin, daß gleichzeitig für die Textgestaltung eine entsprechende Statistik erstellt werden kann, die die absatzweise Textverteilung enthält, die später für die Layoutgestaltung verwendet werden kann.

2.5.4 Vorhandene Erweiterungen

Da der PROLOG-Interpreter keine Steuerzeichen einlesen kann, sollten bestimmte Kennwörter für bestimmte Zwecke reserviert werden, die dann auch für die Kommunikation mit einem Textverarbeitungsprogramm bei der Definition einer Schnittstelle wichtig werden. Für folgende Zwecke würden entsprechende Kennwörter benötigt:

Schreibmodus:

auszeichnen,
unter- und durchstreichen,
kursive Darstellung,
invers kursive Darstellung,
(halb-)fette Darstellung,
hoch- und tiefstellen,
Kapitälchen,
Versalien,

Formatangaben:

tabulieren (links, rechts, zentriert, dezimal),
einrücken (nur links, beidseitig),
zentrieren,
Absatz,
Seitenumbruch,
evtl. mehrere Spalten definieren,
Blöcke definieren,
Platz für Graphiken reservieren,

Stichwortverzeichnisse aufbauen:

Zitat,
Schlagwort,
Titel,
Subtitel,
Marginalie,
Fuß- und Endnote,
Register.

Diese Kennworte sind nur nötig, falls die Implementierung in der Programmiersprache PROLOG beibehalten werden soll. Andere Möglichkeiten der Nutzung vorhandenen Wissens sollen hier noch nicht besprochen werden und bleiben den Schlußbemerkungen vorbehalten.

 

Last Update : June 14, 2002