The tgt-System of Friedman grew out of the necessity to verify or control a formal grammar. It becomes increasingly difficult to con­trol any formal system beyond a certain size: if one wishes to follow the interaction of two or three abstract rules with all their implications,

The new interactive version of the System has actually been installed at the C.N.U.C.E. in order to enable the participants of the Conference to see the systems as it works. I take this opportunity to thank the organizers of the conference, the C.N.U.C.E., and particularly Professor Faedo, Torrigiani, and Zampolli, once again, for their generous support of the demonstration. I also thank my collègues Mrs. Schirmer, Miss Zoeppritz and Mr. Henning, who assisted me to prepare the demonstration. I am especially indebted Dr. Picchi, who adopted the interactive version to the local cms-System.

The form of the Grammar is strictly prescribed, but as already mentioned, it is very close to current transformationalist notation.

For the tgt-System a grammar consists of a phrase structure, a lexicon, and a transformational part. In the first phase of the processing the gram­mar is built up according to the users specifications and in the second, subsequent phase one sentence (or more) are constructed according to the grammar. Each of these major components is subdivided further into smaller units. The structuring of the Grammar is indicated by keywords, which must be used in certain positions and are anticipated by the System.

Let me shortly comment on some points of this scheme of grammar.

Friedman introduced a new type of feature, called contextual, which comprises Chomsky's strict subcategorization and selectional restrictions; i.e., it is all the same for further processing, whether a contextual rule involves features, like (a) or just category symbols, like (b) in (Fig. 1.).

Contextual Rule (a) HUMSBJ = < 5/ < # {ART) N | + HUMAN | %_%» .

(b) DIROBJ = < VP < % NP_>>.

Lexical Entries Imagine \ + V.... + HUMSBJ..

Lexical Insertion 1. Category N V ...

I + HUMAN I

But apart from this simplification, the treatment of these contextual features is significantly different from that of Chomsky's in;the Aspects-model. The main innovation is the concept of the " side effects ", which makes the selectional rules independent of the order of inserting lexical items into the derivational tree.

If the contextual feature refers to a node (or nodes) to which a lexical entry has already been attached, (as in (1) on Fig. 1) the program checks the compatibility of the item with its environment, just as in the Ajpecfo-model. If on the other hand (as in (2), Fig. 1) the node referred to in the contextual rule is still empty, the new item is intro­duced and the consequences of the contextual features, i.e. the feature on which the insertion depends, are projected into the invironment.

Note that the output trees are leaned on the side to simplify print­ing. In addition the nodes are numbered for ease of reference. These numbers can be used, among others to localize the feature, which be­long to a specific node, also with higher, non-terminal nodes. Note also that features coming from the lexicon are associated originally with the lexical entries. After lexical insertion they are adjoined to the immediately dominating category node and not to the actual word any more.

In comparison with the Phrase Structure Rules the notational conventions for transformations are less uniform. The notational un­steadiness is largely due to the lack of a strict, mathematically founded and universally accepted transformational theory.

There are two notational styles in use; the more popular of them is the MIT-Style. (Fig. 2).

Verbal Description of Passive:

MITRE - Notation:

ALESE 2, ARISE 3.

Abbreviations ALESE ... add left sister ARISE ... add right sister MERGEF... merge feature ACHLE ... add by Chomsky ad­junction to the left Fig. 2. Writing Transformations

This convention for transformation is generally advocated in stan­dard introductory works. Accordingly, transformations are written in the form of pseudo-rewriting rules, where apparently, the structural description (SD) part should be replaced by the structural change (SC) part. With other words : you define the input and you define the output. The convention is self explanatory, but perhaps somewhat vague. The MIT notation is regarded even by its own adherents rather as a convenient short-hand for indicating structural changes and not as a proper, full scale formalism.

The other style is the MITRE-notation, which is less known and resembles computer commands. This convention defines the input into a transformation and lists the elementary operations, to be carried out on the input tree. The elementary operations should be defined in advance. On the whole this way of representing transformations is more abstract but it can be formalized more readily. Friedman uses this style of notation: there is no problem to reformulate a trans­formation from the pseudo-rewriting style into the operational representation.

The purpose of the control program (cv) is to determine in which order, and at which point in a derivational tree, a transformation should be applied.

By means of a fortran-like control language (by the so called " traffic rules "), the linguist can execute the transformations cyclically, i.e. applying the same set of transformations to every clause, he can determine in which order the clauses of a sentence should be processed, he may change the order of execution depending on certain condition, e.g. on the success of preceding transformations etc. This control part of Friedman's System provides an enormous generative power, the possibilities of which have hardly been discussed in the linguistics. You can easily define several successive transformational cycles by the cp of Friedman, you can solve the ordering problem of transformations by defining unique jumps in order to leave out the execution of a transfor­mation, which in a " simple ", cyclically ordered grammar would be impossible.

The actual testing of the Grammar is done by the Sentence Gen­erator. As already said the Grammar is laid on in the first phase of the processing and subsequently the system should be instructed to generate sentences according to the given grammar. Trivially in as much as the system generates correct sentences, the grammar is veri­fied to the extent the generated sentences are false, the grammar is wrong and has to be corrected.

The sentence generator as such can operate in one of three nodes (Fig. 3):

A random sentence will be generated

NP ART THE N BOY VP AUX MOD Q TNS PRS V PASS V READ NP PRON WHAT The structure will be operated on according to your grammar

S RES NDOM Q A random sentence will be generated with the restriction that it will not dominate a Q-node Fig. 3. Types of Input into the Sentence Generator

1. It can generate sentences completely at random, where a ran­dom number generator mechanism controls the selection of grammat­ical rules and lexical insertion. All you have to do is to enter the sen­tence symbols S.

The original batch output of the tgt-System has been designed to provide all possible information about the processing, which the linguist may possibly need. First the input grammar is listed, followed by the content of the major internal tables, according to which the subsequent generation procèdes. Then, the process of sentence genera­tion is reported in such a manner, that the linguist can follow the sig­nificant steps of the processing (Fig. 5 (1)).

The present interactive version has been developed according to the experiences gained by working with the original batch version. We have noticed in general that we are interested in the linguistic aspects of the derivation, such as changes in the tree, or in the final output, but not the actual computation.

The demand for a more condensed output will be even more im­perative in a terminal environment where the time and the output should be restricted to a minimum. Therefore we defined a new ad­ditional output file, containing just the essential information in which a linguist is interested (Fig. 5).

The original batch protocol enables you to follow the actual flow of computation, e.g. in the case of a transformation you get the modules called to perform the successive steps of the processing. The interplay of the different subroutines is, however, always the same: ANTEST calls PASSIV, PASSIV calls ELEMOP etc. Since Friedman's System works practically free of error, there is no need to check the subroutine

The Transformations as formulated in the Grammar:

TRANS 1 PASSIV " PASSIVBILDUNG " | OB. SD # 1NP 2NP 3V 4V I + PASS | %. SC (PREP I + DAT I < VON> ) AFIDE 1, I + PART I MERGEF 3, 2 ALESE 1.

The Derivational Tree to he Manipulated on :

The Report on the Successful Completion :

Fig. 5. The Protocol of the Transformations

calls every time. This information, therefore, can be dispensed with for the most purposes.

We have designed a slighdy different, more comprehensive format, which contains only the linguistically relevant information. The new output format of the interactive version makes a clear reference to the input grammar, such as the name of the transformation, the name of the elementary operations, the nodes affected by them. In one point the interactive version provides information, which has not been explic­itly reported in the original batch version. You can follow now also the feature operations in the same form as you follow the tree opera­tions : the interactive protocol delivers the features names and the actual feature value. For a linguist testing feature operations this is an innovation over the original batch version, which suffices to give a hint at this point, that the feature operation has been successfully comple­ted without further details.

It should be noted, that batch-output and terminal output are not mutually exclusive, the terminal output is a summary extracted from the original and placed on a separate file output. The original output is, however, still available. The file on which is written is normally set dummy, but it can be reactivated and listed, in the very same form as in the original version.

The interactive version on the whole uses a fairly straightforward language. The answer to most of the questions is either yes or no (or just the first letter of these words). Every answer is prompted; and should be answered by saying yes or no. In such cases where an other answer is expected the book of Friedman should be consulted. Note that in case you want to enter the input skeleton not from the terminal you must have the file allocated prior to calling the tgt-System.

Summarizing: if you want to run the tgt-System you have to define and enter a grammar, give a command for the sentence gener­ator, and you have to deliver a skeleton to be expanded (Fig. 6). Orig­inally all these three kinds of input were entered in sequence into the system on the same file as data.

It should be noted that the grammar is a part of the input data, which is entered and processed in each run. This homogenous input is then interpreted by the system as grammar or as input into the sen­tence generator according to the internal logics of the program. In order to achieve greater flexibility while testing a grammar, we sepa­rated the three logically different input into three logically different files. The input grammar, usually a text of several hundreds of lines,

Batch Input Interactive Input Fig. 6. The Reorganization of Input

is normally already stored on an external device and entered accord­ingly. The generator command (the $MAiN-card) may be attached to the grammar, if not, it is prompted and you may enter it from the terminal.

Similarly, you may predefine input skeletons to be tested and enter them just as you enter the grammar as a separate file. You have, how­ever, the choice to enter skeletons directly from the terminal. In case of interest you may enter as many skeleton as you like. The random generator then provides for variation.

Technically, the separation of the three logically different kinds of input has been accomplished by introducing a file variable, which is set first to accept the grammar from a permanent data set and then changed over to the terminal or an other permanent input data set ac­cording to user specifications at session time.

The same file variable technique is used to control the error mes­sages. The error file is set either to the terminal or to the batch file al­ternatively. There would be no problem to assign the error messages permanently, yet an eventual change of the file requirements in ter­minal environment would mean a revision of several hundreds of er­ror messages, while a file variable can be controlled by a single instruc­tion.

There is a further problem to be faced and that is the reference point of the error message. In the original batch version the error mes­sage precedes the actual erroneous line in the grammar or inserted in the protocol at the appropriate point.

In the first case the interactive version does not display the original input grammar, and therefore a message that e.g. brackets are opened, but not closed or "special character expected", but not found, and the like are not very informative, since the user would be left alone to find the critical place in the grammar. Therefore the error messages during the processing of the input grammar are preceded by the actual line in which the error has occurred. The line numbering will help the linguist to localize the erroneous section in the input grammar.

If on the other hand the error occurs during sentence generation, the message will be inserted in the terminal protocol at the appro­priate place.

Another crucial point is the control of the terminal output. You can have the following choices as regards extent of output:

1) You are not interested in any further details, you do not want to see the full input tree. In this case you still get: 1., the linear representation of the input, 2., the list of transformations which have been applied and 3., the output of the transformations, also in the linear form. This is the minimal amount of output (Fig. 7) :

2) You wish to see the input tree into the transformational com­ponent, you answer to the question PRINTOUT INPUT TREE? by saying " yes ". In this case you get also the full output tree of the

SEH JEMAND HANS NICHT FRGZ ENTER GENERATOR INPUT AS TRIN

TRIN .NO MORE INPUTS. READY Kg- 8.

ADDED SUBTREE: 21

istvân bâtori

Fig. 9.

PREP ART N V

4) You may be interested in even more details, for instance in some intermediate trees and you have inserted trace-cards in the con­trol program of the grammar just as they are inserted in the original batch version. Now if you answer to the question PRINTOUT IN­PUT TREE by saying ALL, you will receive every intermediate tree as well, in addition to the input and output tree with features and fea­ture operations. Otherwise the trace function returns just the terminal string of the derivation. Fig. 10 shows the general logics of the output control:

Fig. 10. The Control of Interactive Output

A grammar developed directly with the aid of the TGT-System is practically never complete, it generates only a subset of the language in question. You may add, change, remove parts of the grammar and thus you can easily produce minor variants of the same grammar one of which may be preferable over the other. In fact this is the nor­mal way to work with the system.

At the C.N.U.C.E.-installation there was a number of test-gram­mars (German, Italian, English and Spanish), offered to the participants to try how such testing looks like. The participants of the Conference were invited to look at the Grammar Tester as it works. In the Centro Nazionale Universitario di Calcolo Elettronico the Transformational Grammar Tester was running on a ibm System/360 Model 67 under cp-cms-67.