in: O. Herzog and C.-R. Rollinger (eds.), Text Understanding in LILOG, Springer, Berlin, 1991
A Flexible Parser for a
Linguistic Development Environment Gregor Erbach
Abstract
We describe the parser of LEU/2, the Linguistic Experimentation Environment of the LILOG project. The parser is designed to support and encourage experimentation with different grammars, different styles of writing grammar, and with different parsing strategies.
Unlike the parser of the first LILOG prototype, which was designed specifically for Categorial Unification Grammars (Uszkoreit 1986), the present parser places hardly any restrictions on the format of the grammar, and also supports rules in ID/LP-format (Gazdar et al. 1985) under two interpretations of LP statements. Empty categories can be processed. The parser includes a mechanism for processing unknown words, and for determining sentence boundaries in continuous text.
The parser is a bottom-up chart parser for grammars encoded in STUF (Bouma, König, Uszkoreit 1988).
Although the emphasis of the parser is on experimentation with different grammars rather than efficient analysis of texts, we have tried to make the parser as efficient as possible to make it a powerful experimentation tool for the grammar designer. In order to implement parsing strategies, the parsing process is decomposed into individual parsing tasks, which are placed onto an agenda (Kay 1980) according to their priority.
This paper consists of two parts. In the first part, we discuss various choices in parser design, and motivate our design decisions by the use of the parser in a linguistic development environment. In the second part, the parser is described in more detail. Some familiarity with chart parsing is assumed.1
Introduction
In order to understand some of the choices we made in the design of the parser, it is necessary to have some information about the process of grammar development, the software environment used by grammar developers, and about the place of the parser in such an environment.
State-of-the-art grammar development environments support the following activities:
— writing and editing a grammar,
— parsing one or more sentences to verify the grammar,
— inspection of the parse results.
This sequence of steps is repeated until the linguist is satisfied with the grammar, based on the parse results. This style of working imposes the following requirements on the parser:
1 For an introduction to chart parsing, see (Kay 1980) or (Seiffert, this volume).
- It should be reasonably efficient so that the user is not kept waiting for parse results.
- It should be transparent to the user how the parse result was constructed, and what the analyses are for substrings of the sentence that was parsed.
- In case of failure to parse a string, it should be possible to give a reasonable output that helps with the diagnosis of the error and the debugging of the grammar.
Choices in Parser Design
Parsing technology provides various choices in the design of a parser, relating to
— the types of grammars that can be processed (specialization vs. generality),
— expectation-driven (top-down) vs. data-driven (bottom-up) processing,
— dealing with non-determinism (parsing strategies).
Each of these issues will be discussed in the following, and the choices taken will be motivated by the use of the parser in an environment for the development of grammars and experimentation with parsing strategies.
Types of Grammars
There are various degrees in which a parser can be specialized for particular grammars:
— The parser can be specialized for one particular grammar (according to a particular linguistic theory) of one particular language. In this case, there is no separation between grammer and parser. This is the most extreme degree of specialization, which would be appropriate for a commercial parser, used in a natural-language interface, which must operate under severe constraints of time and space.
— The parser can be specialized for one particular linguistic theory, like Government-Binding Theory (Chomsky 1981), Lexical-Functional Grammar (Kaplan, Bresnan 1982), and numerous others. This allows a gain in efficiency by exploiting the structural constraints inherent in these theories, while it makes it possible to use different grammars for different languages within the framework of a given grammatical theory.
— The parser can process any grammar encoded in a general formalism like Functional Unification Grammar (Kay 1985), PATR-II (Shieber et al. 1983), or STUF (Bouma, König, Uszkoreit 1988). But even with such very general formalism, it is still possible to interpret rules in different ways. For example, a rewrite rule like
S -> A B C
can be interpreted as a rule of a context-free grammar, in which case S can only be rewritten as the sequence
"A B C", or the rule can be interpreted as an immediate dominance rule, in which S can be rewritten as any permutation of the right-hand-side (i.e., "A B C", "A C B", "B A C", "B C A", "C A B", or "C B A"). In this repect, grammar is an open-ended concept, and it is the grammatical formalism and its interpretation by the parser that limit the range of possible grammars that can be processed. This option is the most inefficient one, but it allows the highest degree of freedom in the development of different grammars.
Our parser is not restricted to any particular linguistic theory, and can process the types grammar rules discussed below. While the grammars for the first prototype were Categorial Unification Grammars (Uszkoreit 1986a), the current grammar is based on HPSG (see Kiss 1991, this volume, for an explication of the grammar).
Another option that needs to be considered is preprocessing or compilation of the grammar. Such preprocessing may range from conversion to some normal form to the generation of a parser for a particular grammar. We have chosen not to use any preprocessing, so that the parser operates directly on the grammar. This makes it easier to build tools to inspect the parse results, and to relate the parse results to the grammatical knowledge bases, i.e., the syntax rules and the lexicon.
Top-Down or Bottom-Up Analysis
There is in general a choice between data-driven (bottom-up) and expectation-driven (top-down) analysis. Both choices have their advantages and disadvantages:
Bottom-up analysis has the advantage that the choice of the grammar rules that are applied depends on the words present in the sentence and on analyses for substrings of the sentence. However, the disadvantage is that analyses for substrings are built up, which do not contribute to the overall analysis of the sentence.
Top-down parsing has the advantage that only such rules are applied which can be useful in proving that the sentence is grammatical. The disadvantage is that the rules are tried "blindly", without any regard to the lexical material present in the sentence.
The advantages of both top-down and bottom-up parsing are combined in "directed" parsing strategies (Kay 1980), as for example in left-corner parsers (Pereira, Shieber 1987), or head-driven parsers (Kay 1989).
We have chosen pure bottom-up parsing for two reasons:
— Our grammars do not need to have a context-free backbone to guide top-down analysis, or support the creation of a link table which is needed for the "directed" methods. Nor can we rely on any properties of the grammar to implement a "head-driven" parsing algorithm (Kay 1990), because the linguist has complete freedom in writing the grammar.
— In grammar development, one is not only interested in the overall parse of the sentence, but also in analyses of the substrings. So what is generally claimed to be a drawback of bottom-up parsers, the creation of analyses for substrings, which are never used in the analysis of the sentence, turns out to be an advantage for our purposes.
Dealing with Non-determinism
Non-determinism in parsing arises when several different parsing tasks can be performed at the same time. Since parallel processing is not available to us, we must have a way of choosing a parsing task.
Deterministic parsing (Marcus 1980) is not appropriate for grammar development, because Marcus' deterministic parser requires a grammar format (of situation-action rules) which is not declarative and not very intuitive linguistically.
A simple backtracking parser cannot be used for reasons of efficiency. It does not store intermediate results so that a lot of work has to be done repeatedly.
We have chosen chart parsing because it stores intermediate results and avoids duplication of effort. Storage of intermediate results is useful because the linguist developing and debugging a grammar is not only interested in the overall parse result, but also in the analyses that his grammar produces (or does not produce) for substrings of the sentence.
Chart parsing leaves open the question of the search strategy, i.e., the selection of the next parsing task. Our chart parser allows for the definition of arbitrary parsing strategies, so that it is also a tool for experimentation with different strategies.
Description of the Parser
In the following, we will give a technical description of the parser, focusing on the data structures, the parsing algorithm, the processing of LP statements, empty categories, unknown words and the implementation of parsing strategies.
The parser can process grammars encoded in STUF, the Stuttgart Type Unification Formalism (Bouma, König, Uzskoreit 1988) which may contain the following types of grammatical information:
— lexical entries, which associate word forms with feature structures.
— lexical rules, which create lexical entries from lexical entries.
— CF rules, which have information about both dominance and linear precedence; the order of the right-hand side of the rule reflects the order of the constituents in the string2.
— ID rules, which just have information about dominance, not about linear precedence.
— LP statements, which constrain the linear precedence of constituents.
— the Start Graph, a feature structure which defines what a well-formed sentence of the language is; nothing counts as a parse result unless it unifies with the Start Graph.
The parser needs lexical entries, and a set of ID rules or CF rules. Lexical rules and LP statements can be processed, but they are not essential for the operation of the parser. It is possible to have both CF rules and ID rules in one grammar, so that it is possible to describe languages in which some constructions are fixed and others allow for permutation.
Data Structures
The central data structure of the parser is the chart, which is a set of chart items. Chart items may be passive (complete constituents) or active (constituents which are still missing something).
Chart items:
passive: <Start, End, Item, FS, Daughters, Evaluation>
active: <Start, End, Item, FS, Daughters, Evaluation, LHS, RHS>
2 They are called CF-rules because they share this property with context -free rewrite rules. However, the grammar formalism is equivalent to type-0-grammars.
where
— Start is the starting position of the item.
— End is the ending position of the item.
— Item is a unique identifier of the item, a number.
— FS is the feature structure of the item. In the case of passive items, it represents a grammatical category, and in the case of active items, it represents a partially instantiated grammar rule. A grammar rule has a feature for its left-hand side and each of the elements of its right-hand side.
— Daughters is a list of identifiers of the items that were used in building the current item, and the name of the rule.
This information is needed for reconstructing phrase structure trees for parse results.
— Evaluation is a numerical value that associates with the item a probability or qualitative rating, which will be discussed in the section on parsing strategies. This evaluation for an item must not be confused with the priority of a parsing task.
— LHS is a feature under which the left-hand side of the grammar rule is found after an active item has been completed.
— RHS is a list of features, which indicates how many more constituents are needed to make the active item passive, and with which features of the rule their feature structure must be unified.
The other fundamental data structure is the agenda, an ordered list of parsing tasks. A priority is associated with each parsing task. The parser can process the following parsing tasks:
— a_and_p( act(X), Item1, Item2 )
Combine an active item (Item1) with a passive item (Item2). act(X) can have the values act(ID) or act(CF) depending on whether the active item originated from the application of an ID rule or an LP statement. If it originated from a CF rule, the next element of the remaining right-hand side of the active item must be unified with Item2; if it originated from an ID rule, any element of the remaining right-hand side may be unified with Item2.
— unary_rule( RULE-NAME, Item1 )
Apply the unary rule with the RULE-NAME to the passive item Item1, thereby creating a new passive item if the rule application was successful.
— binary_cf_rule( RULE-NAME, Item1, Item2 )
Apply the binary CF rule RULE-NAME to the passive items Item1 and Item2, creating a new passive item if the rule application was successful. Binary rules are treated specially for reasons of efficiency. The option for treating binary rules specially can be turned off, in which case binary rules are treated with the parsing task cf_rule(RULE-NAME, Item).
— binary_id_rule( RULE-NAME, Item1, Item2 )
Apply the binary ID rule RULE-NAME to passive items Item1 and Item2. Since ID rules do not prescribe the order of the constituents, there will be two tasks on the agenda (binary_id_rule(NAME, Item1, Item2) and binary_id_rule(NAME, Item2, Item1)) in the general case. However, if we can tell beforehand by application of a filter (see below) that one of these options will fail anyway, it will not be put on the agenda.
— cf_rule( RULE-NAME, Item1 )
Apply the CF rule RULE-NAME to the item Item1, creating an active item if the rule application was successful.
— id_rule( RULE-NAME, Item1 )
Apply the ID rule RULE-NAME to the item Item1. Since ID rules do not prescribe the order of the constituents, any element on the right-hand side of the rule may be unified with the item Item1. Thus, the rule application may create as many active items as there are elements on the right-hand side of the rule.
The Parsing Algorithm
The parsing algorithm is extremely simple: after initialization of the parser (and creation of an initial agenda), the task with the highest priority is taken from the agenda and executed. Execution of the task may produce new tasks which are added to the agenda. The parser will continue executing the highest-valued task of the agenda until a parse for the sentence has been found or the agenda is empty.
Phase 1: Initialization
unless there is a chart and agenda3: read next sentence from input stream
for each word of the sentence, perform lexical lookup and add a passive item to the chart (thereby generating new parsing tasks)
order the parsing tasks and create an inital agenda
Phase 2: Parsing Loop while the agenda is not empty
take the task with the highest priority off the agenda and execute that task if it succeeds, add a new item (thereby generating new parsing tasks) order new parsing tasks into the agenda
if that item is passive, covers the entire string and unifies with the Start Graph then stop
Add an Item I to the Chart store the item I
— for every unary rule UR, create a task unary_rule(UR,I)
— for every binary CF rule(BR), and every right-adjacent item RI, create a task binary_cf_rule(BR,I,RI)4
— for every binary CF rule(BR), and every left-adjacent item LI, create a task binary_cf_rule(BR,LI,I)
— for every binary ID rule, and every adjacent item AI, create tasks binary_id_rule(BIR,AI,I) and binary_id_rule(BIR,I,AI).
3 There may already be a chart and an agenda, if one parse result was found, and the parser is restarted in order to look for another analysis of the sentence. Before parsing a new sentences, the chart and agenda for the previous sentence are deleted.
4 We assume here that binary rules are treated specially, for reasons explained below.
— for every more than binary CF rule R, create a task cf_rule(R,I).
— for every more than binary ID rule R, create a task id_rule(R,I).
— if the item I is active, for every right-adjacent passive item P, create a task a_and_p(I,P).
— if the item I is passive, for every left-adjacent active item A, create a task a_and_p(A,I).
Perform a Parsing Task
See the above description of the parsing tasks.
Order the Parsing Tasks
Each parsing task as assigned a priority based on any information which may be available about it, for example the rules involved, the feature structures of the items involved, the length of the resulting item, the position in the resulting item. In this way arbitrary parsing strategies can be implemented (see below).
LP Constraints
The grammar formalism STUF includes LP constraints which control the linear precedence of constituents. LP constraints can be interpreted in various ways. The classic interpretation (Gazdar et al. 1985) is that LP constraints determine the relative order of sister constituents. However, it is linguistically interesting to experiment with different interpretations which allow ordering constituents that are not sisters5. A domain in which to enforce LP constraints are all complements and adjuncts of a lexical head.
It is up to the grammar writer to specify the domain within which LP constraints are enforced. For this reason, the grammar must be augmented in such a way that a list of constituents is built up in the feature structure of a constituent. The LP constraints are checked on the elements of the list.
The following example makes use of a difference list encoding which allows the concatenation of lists of arbitrary length by unification (Sterling, Shapiro 1986). The feature 'list' is used for the list, and the feature 'var' for the rest variable. The list is encoded with the features 'first' for the first element, and 'rest' for the rest of the list. In the example, the rules of Right-Complementation and Left-Complementation are augmented such that they build up a list of the head's complements.
Right-Complementation :=
mother -> head comp
<mother, lp_list, list> = <head, lp_list, list>
<head, lp_list, var, first> = <comp>
<mother, lp_list, var> = <head, lp_list, var, rest>
Left-Complementation :=
mother -> comp head
<mother, lp_list, list, first> = <comp>
<mother, lp_list, list, rest> = <head, lp_list, list>
<mother, lp_list, var> = <head, lp_list, var>
5 For a linguistic motivation of the need for interpreting LP statements in hierarchical structures, see (Uszkoreit 1986b).
Empty Categories
Linguistic theory makes use of empty categories for a constituent that has been 'moved' from one position on the phrase structure tree to another. Empty categories are not strictly necessary, because their effect can be simulated by adding more rules to the grammar. Nevertheless, their use may be more convenient to the grammar writer6. For working with empty categories, the grammar writer must specify what the information content (the feature structure) of possible empty categories is. Empty categories are implemented by adding an item from each position of the chart to the same position, thus covering none of the input string. We do not constrain the introduction of empty categories, but this could be done by treating the introduction of an empty category at some position in the chart as a normal parsing task, which can be assigned a priority by a parsing strategy. Thus it would be possible to introduce empty categories only if certain conditions are met.
Unknown Words
If an unknown word is encountered during lexical lookup, the parser does not simply fail, but rather makes the assumption that the word is a member of one of the open word classes (nouns, verbs, adjectives) of the language in question. A disjunction of these categories is then used as a preliminary (highly underspecified) lexical entry, which the parser uses for analysis of the sentence.
If the parsing succeeds, the parse result will be somewhat underspecified (e.g., for the semantic contribution of the unknown word). It is then possible to compute the constraints of the parse on the unknown word, and thus obtain some information about the unknown word. This method and its applications for automatic extension of the lexicon are discussed in (Erbach 1990).
Sentence Boundaries
In a continuous text, it is not always clear where the sentence boundaries are. Punctuation is not a clear indication because (in German), the period is also used to indicate an abbreviation and an ordinal number. It is the job of the parser to determine sentence boundaries in a text. For this purpose, the algorithm given above is somewhat extended. The parser is presented with a string of words up the the next possible punctuation mark. If this string cannot be analyzed as a sentence, the parser requests the words up to the next punctuation mark, and extends the chart. The parsing process then proceeds with this longer sentence candidate.
Efficiency
While the parser is intended for use with a grammar development and experimentation environment, and not for large-scale text processing, efficiency has nevertheless been a major concern, because we want to minimize the waiting time for the user.
We consider two problems: the proliferation of active items which causes a waste of space, and the problem of useless parsing tasks which causes a waste of time.
6 As far as efficiency is concerned, a large number of unary rules is just as disastrous as having empty items in the chart.
The proliferation of active items is due to the fact that principle-based or categorial grammars use very general rules. It will often be the case that that a rule can be applied to item, resulting in an active item which then cannot be combined with any other item to from a complete consituent. A very large proportion of the storage space used in the parsing process is consumed by active items, which generally contain large feature structures. For this reason, we treat binary rules specially without introducing active items.
By not creating active items, there is some work that must be done repeatedly, however. Consider the following situation in the chart:
|---A---|---B---|
|---C---|
|---D---|
If there is a binary rule R, we can now create three parsing tasks: apply R to item A and item B, apply it to item A and item C, and apply it to item A and item D.
Applying the rule R to items A and B means unifying it first with the feature structure of item A, and then with the feature structure of item B. If the unification with item A fails, it will fail for the other two parsing tasks as well.
Therefore the parser records that applying rule R to item A as the first element of the RHS has failed, and knows consequently that all tasks of the form
binary_rule(R,A,?) will fail as well.
Since the largest proportion of binary rule application fails, we retain one advantage of using active items, namely that we do not try a failing unification a second time. However, for unifications that do succeed, we do not store intermediate results, because this would be exactly the same as creating an active item, which causes the space problems mentioned above.
The second problem concerns useless parsing tasks, that is, parsing tasks that do not succeed. There are two reasons for filtering out these useless parsing tasks. The first is that the computational cost of executing these parsing tasks should be avoided, and the second is that there is no point in giving these failing tasks a priority and adding them to the agenda.
While in general, there is no way of telling which task is going to fail and which is going to succeed (unless the task is performed!), a large proportion of rule applications can be eliminated by a computationally inexpensive filter.
For every rule and every passive item we compute a Prolog term which contains only a subset of the information of its feature structure, i.e., it subsumes the feature structure. Before the task is added to the agenda, the Prolog terms associated with the rule and the items are unified. If this unification fails, we know that the task is also going to fail, and it is not added to the agenda. With this method, a large proportion of the failure-bound parsing tasks can be filtered out. Because Prolog unification is much cheaper than unification of STUF terms, a large amount of time is saved this way.
Parsing Strategies
By a parsing strategy, we mean a method for choosing among several possible parsing tasks by a method for assigning a priority to a parsing task. There are three objectives for using explicit parsing strategies instead of simple depth-first or breadth-first search:
— reduction of the search space
— finding the intended reading for ambiguous sentences
— creating a model of human sentence processing
We will focus here only on the first two issues, leaving the third to psycholinguistic research. It should be noted that a parsing strategy is not useful if one wants to have all possible analyses of a sentence, because this requires exploration of the complete search space.
The motivation for using parsing strategies is mostly one of efficiency. First of all, the objective of a parsing strategy is to find an analysis of a sentence with minimal effort. Moreover, in the face of ambiguity, there are two sources of inefficiency: firstly the exploration of the complete search space and secondly the effort involved in deciding which reading is the intended one. We hope that the use of a parsing strategy will overcome both of these problems.
For reduction of the search space a strategy can be constructed automatically by measuring how many times rules are applied, and assigning a high priority to those parsing tasks which involve rules which frequently contribute to a successful analysis. In order to obtain the data necessary for the definition of parsing strategies, the parser collects statistics on how often each rule is attempted, how often it is successful, and how often it contributes to the final parse result.
Finding the intended reading can only be achieved by close interaction with semantics and discourse representation. The idea is to filter out semantically implausible readings as soon and as locally as possible. Such early semantic processing results in the evaluation of chart items according to their plausibility. These values of the items will then be used in the calculation of priorities for tasks involving these items. Another possible source providing input for the evaluation of chart items are LP constraints, whose violation decreases the acceptability of a sentence, but does not make it completely ungrammatical. The evaluation of chart items is still largely uncharted territory and a matter of future research.
The architecture of the parser provides a framework in which research on parsing strategies can be conducted.
Our experimentation suggests that a parsing strategy which assigns tasks a priority according to the rule which is involved in the parsing task can reduce the search space significantly.
Let us now turn to the question how parsing strategies are implemented. A parsing strategy means choosing an order in which the different parsing tasks are executed. In order to achieve this, each parsing task is assigned a priority. This priority is a function of the information that is available about the parsing task (and other information about the chart as well). To illustrate the implementation of parsing strategies, we provide examples of some evaluation functions. The absolute value of the priority is irrelevant; only the relative value compared to the values of other parsing tasks is needed.
depth-first
Every new parsing task must be given higher priority than the older parsing tasks. This can be achieved, for example, by taking the system time as value for the priority7.
priority(TASK) = system_time breadth-first
Every new parsing task must be given lower priority than the older parsing tasks. This can be achieved by making the inverse of the system time the value for the priority.
priority(TASK) = 0 — system_time right-to-left
priority(TASK) = 0 — starting_position of resulting item long strings first
priority(TASK) = length of resulting item unary rules first
priority(TASK) = 1 if a unary rule is involved, and 0 otherwise frequently used rules first
In our experiments, this has proved to be the most successful and effective parsing strategy. See (Erbach 1991) for more details.
priority(TASK) = frequency of the rule involved in the task
Options of the Parser
The parser has a number of options which control its behaviour. Some options enforce a different interpretation of the grammar and add to the power of the parser, and may thus yield different parses, while others concern the internal representatio n of items and the order of enumeration of the parse results.
We will first consider those options that make the parser more or less powerful and cause it to yield different results:
7 In reality, we implement a depth-first-strategy by assigning the same priority to all tasks. When a task is added to the agenda, and there is already a task with the same priority, the new task is placed before the old one.
LP constraints LP constraints may be interpreted either for sister constituents or in user-defined domains (in hierarchical structures), as described above, or they may be ignored completely.
Empty categories The introduction of empty categories may optionally be suppressed.
Punctuation A grammar may or may not contain lexical entries and rules that deal with punctuation. This option specifies whether the parser ignores punctuation or treats each punctuation mark as one word.
Unknown words The processing of unknown words may be turned off, in which case the analysis fails if an unknown word is encountered.
Addition of features While the parser is running, it may add features to the feature structure of chart items.
There is one feature that gives each item a unique name, e.g., the number of that item.
Another feature for lexical items encodes whether or not the word was capitalized. This is useful if the grammar writer wants to exploit information about capitalization of a word at the start of a sentence.
The third dynamically added feature relates to the position of the item in the chart. The position feature has two features, one for the starting vertex of the item, and one for the ending vertex. This feature can be exploited to encode word order regularities, to check for adjacency of items.
For example, an equation like <cat1, pos, end> = <cat2, pos, start> would specify that cat1 is followed by cat2.
The following options do not change the language accepted by the parser, but rather its efficiency, and the order in which the parse results are enumerated.
Complete search This option gives two choices:
— All parses are enumerated, which is useful for testing the grammar, and finding out which ambiguities are present. This option is also useful if one has no way of knowing which reading is the correct one.
— The parser stops after one analysis has been found. More analyses can be searched for by restarting the parser from the state in which the first parse had been found. For this purpose, the chart and the agenda are saved. This option is useful if a parsing strategy has been defined.
Binary rules Binary rules can be processed with or without creation of active items. The consequences for the efficiency of the parser are discussed above.
Useless task filter The filter for useless rule applications (see above) may be turned off. This is useful for checking the efficiency gain achieved by different filters. The user may choose which paths of the feature structure are included in the filter.
Parsing strategy The user may select one of the parsing strategies. New parsing strategies can be defined by writing an evaluation function for parsing tasks.
Conclusion
We have given an overview of the choices in parser design, and motivated the choices we have taken in light of the use of the parser for a linguistic development environment. The use of a parser in a linguistic development environment is necessary in order to check whether the grammar accepts the sentences it should and assigns them the correct structures. State-of-the-art linguistic development environments consist of an editor, a parser, and a tool for inspecting parse results.
Such an parser-based environment does not offer means for checking whether the grammar overgenerates, nor does it offer any convenient way of checking why the analysis of a particular sentence has failed. For these purposes, a linguistic development environment must be extended by two components:
— A generator which will produce a representative sample of sentences for every grammar. The set of produced sentences is restricted to a manageable size by using only a subset of the lexicon with only one member for every word class, by limiting recursion and the length of the sentences produced. Such a system has been implemented and is described in (Arens, Erbach 1991)
— A means for selecting linguistic objects (lexical entries, chart items, grammar rules), and unifiying them with each other. In case of a unification failure, the system should indicate why the unification has failed. Such a functionality is useful for determining the source of an error in the grammar if the analysis of a sentence has failed unexpectedly.
References
Arens, R. G., Erbach, G. (1991): ??? Titel ???. In: Proceedings of GWAI '91.
Bouma, G., König, E., Uszkoreit, H. (1988): A flexible graph-unification formalism and its application to natural- language processing. In: IBM Journal of Research and Development 32(2), pp. 170-184
Chomsky, N. (1981): Lectures on government and binding. Foris, Dordrecht
Erbach, G. (1990): Syntactic processing of unknown words. In: Jorrand, P., Sgurev, V. (eds.): Artificial Intelligence IV, methodology, systems, applications. North-Holland, Amsterdam
Erbach, G. (1991): An environment for experimenting with parsing strategies. In: Proceedings of IJCAI '91, Sydney Gazdar, G., Klein, E., Pullum, G., Sag, I. (1985): Generalized phrase structure grammar. Basil Blackwell, Oxford Kaplan, R., Bresnan, J. (1982): Lexical functional grammar: a formal system for grammatical representation. In:
Bresnan, J. (ed.): The mental representation of grammatical relations. MIT Press, Cambridge, MA, pp.
173-281
Kay, M. (1980): Algorithm schemata and data structures in syntactic processing. Report CSL-80-12, XEROX PARC, Palo Alto, CA
Kay, M. (1985): Parsing in functional unification grammar. In: Dowty, D., Karttunen, L., Zwicky, M. (eds.): Natural language parsing. Cambridge University Press, Cambridge, UK
Kay, M. (1989): Head-driven parsing. In: Proceedings of the international workshop on parsing technology.
Carnegie-Mellon University, Pittsburgh, PA
Marcus, M. (1980): A theory of syntactic recognition for natural language. MIT Press, Cambridge, MA Pereira, F., Shieber, S. (1987): Prolog and natural language analysis. CSLI Lecture Notes 10, Stanford, CA Pollard, C., Sag, I. (1987): Information-based syntax and semantics, Vol. 1: fundamentals. CSLI Lecture Notes 13,
Stanford CA.
Shieber, S., Uszkoreit, H., Pereira, F., Robinson, J., Tyson, M. (1983): The formalism and implementation of PATR-II. In: Grosz, B., Stickel, M. (eds.): Research on interactive acquisition and use of knowledge.
Stanford Research Institute International, Menlo Park, CA
Sterling, L., Shapiro, E. (1986): The art of Prolog. MIT Press, Cambridge, MA
Uszkoreit, H. (1986a): Categorial unification grammar. In Proceedings of COLING '86, pp. 187 - 194, Bonn, Germany
Uszkoreit, H. (1986b): Linear precedence in discontinuous constituents: complex fronting in german. CSLI-Report 86-47, Stanford, CA
