User Specification of Syntactic Case Frames in TELI, 
A Transportable, User-Customized Natural Language Processor 
Bruce W. Ballard 
AT&T Bell Laboratories 
600 Mountain Avenue 
Murray Hill, NJ 07974 
1. Introduction 
In this paper, we present methods that allow the 
users of a natural language processor (NLP) to define, 
inspect, and modify any case frame information 
associated with the words and phrases known to the 
system. An implementation of this work forms a critical 
part of the Transportable English-Language Interface 
(TELI) system. However, our techniques have enabled 
customization capabilities largely independent of the 
specific NLP for which information is being acquired. 
The primary goal of the syntactic acquisitions of 
TELI is to redress the fact that many NL prototypes 
have failed (1) to make known to users exactly what 
inputs are allowed (e.g. what words and phrases are 
defined) and (2) to meet the needs of a given user or 
group of users (e.g. appropriate vocabulary, syntax, and 
semantics). Experience has shown that neither users nor 
system designers can predict in advance all the words, 
phrases, and associated meanings that will arise in 
accessing a given database (cf. Tennant, 1977). Thus, we 
have chosen to make TELl "transportable" in an 
extreme sense, where customizations may be performed 
(1) by end users, as opposed to computer professionals, 
and (2) at any time during English processing. 
The current prototype of TELI, which runs on a 
Symbolics Lisp Machine, derives from work at Duke 
University on the LDC project (Ballard, 1982; Ballard, 
1984; Ballard, Lusth, and Tinkharn, 1984; Ballard and 
Tinkham, 1984). The top-level menu of TELl, and also 
a sample snapshot of a session with TELl, which may 
give the flavor of how the System operates, are shown in 
Figure 1. A discussion of semantic acquisitions 
appeared in Baltard and Stumberger (1986). 
2. The Importance of Case Frame Information 
Following Ballard and Tinkham (1984), TELI 
seeks to enable domain-independent English processing 
by maintaining detailed case frame information about 
the phrase types provided for by the system. For 
example, when accessing a restaurant database, the 
system would know not only that "serve" is a transitive 
verb but also that it requires objects of type Restaurant 
as subject and either Food or Meal as object. Thus, if 
"Japanese" is known to be a type of Food, and "lunch" a 
Meal, then the system would accept 
"Which restaurants serve lunch?" 
"How many restaurants serve Japanese food?" 
and reject 
.... Which meals serve Japanese food?" 
* "How many meals serve a restaurant?" 
As a more elaborate example, suppose we are accessing 
information about researchers at Bell Labs, and we ask 
"Which manager does the newest speech employee 
not in building two report to?" 
The exact phrase types involved in the above input are 
Verb Phrase: (employee report nil nil to manager) 
Prepositional Phrase: (employee in building) 
Noun-Noun Phrase: (project employee) 
where "nil" denotes unfilled optional slots for direct 
object and particle. Adverbials ("not") and inflections of 
single-word modifiers ("newest") are handled by 
mechanisms separate from those associated with what 
we are calling phrase types (see Section 9). 
As suggested above, we treat the noun being 
modified by a prepositional phrase as an argument of the 
modifier in question (e.g "in"). Thus, departing from 
more conventional treatments, our "head noun" is part 
of the prepositional case frame, which therefore 
comprises three rather than two slots. Similarly, 
adjective phrase case frames comprise four rather than 
three slots (see Section 5). Our syntactic and semantic 
treatment of prepositional phrases is suggested by the 
"Intermediate Representation" shown in Figure 1. 
3. Situations In Which Case Frames May Be Considered 
There are presently five situations in TELI where 
users are able to examine and possibly modify syntactic 
case frames. The first of these occurs during initial 
customization, when the system first confronts a new 
454 
5El,IT ......................... -ZL~---- == ............................ _~ 
NOUN NOT PEL .............. ~..~<:.-~ ...... -~ ........... .. EMPLIOYEE PRE~-PH 
','EP6 FPE;:' :,u} ar',3 
.......... .................. .OIRK ol, !   oub,t. 
it, l ...... " ....................... • NIJUN NI)UNU,qL S P E\[E C H 
OEPflRITIIENT ±1~25 
English Input: 
Nhich employees not in department 11225 are Norking on speech 
Internal Representation: 
(EMPLOYEE (VERBINFO (EMPLOYEE WORK NIL NIL OM PROJECT) 
(SUBJ ?) 
(ARG (PROJECT (= SPEECH)))) 
(NOT (PREPINFO (EMPLOYEE I~ DEPORTMENT) 
(SUBJ ?) 
(BRG (DEPARTMENT (= 11225)))))) 
Olgebra Query: 
(SELECT 
(TJOIN mh-nl(name) = project-info(emp))(name org proj) 
(and (!= org 11225) 
(= proj 'speech))) 
Answer: ( ROJEC.I EO) 
:. ,,ME 
BaCHENKO \[1138~ISPEECH I TZPBTRICKIIt3841~ 
Figure 1: Sample Display Screen; Top-Level Menu of TEL1 
What's Your Pleasure? 
,~\]n$~,,icr- 19 I~!u65tiot\] 
Edit the La:;L Input, 
Print FIar:,~. )r~_:c 
Frl.ltl I;'iCL-{E, i?l: thc NLF' 
Es:il. 
E;¢~qir, a I~,tl:st,_~lrlizat.i,<,Fi 
Uocabularv 
q >.,'n ta ;,; 
SF.Krqant ic~5 
6cneral Info ......................... 
.......................... 
Clear Screen 
Edit 61obal Flags 
'~av~;/Ret.riev~ 5e:ssiorl 
database. The remaining four, which concern the 
central English processing mode of TEL1 relevant to 
this paper, are as fellows. 
When explicitly requested by the user. When logging on 
to the system, or at a later time, uscrs can ask what 
words and phrases are associated with a particular 
domain object. This contributes to the habitability of 
the interface. 
When adding new vocabulary items. For example, if the 
user specifies "open" as an adjective, the system asks for 
its associated case frames. 
When attempting to recover front a parsing failure. For 
example, if a sentence that the system cannot parse 
contains the word "with", the system will offer to show 
the user all existing prepositional triples of the form 
Entity-with-Fntity. This permits the user to ascertain 
whether the parsing failure was caused by missing case 
frame information or for some other reason. If the 
problem is due to missing case frame information, the 
user can add it, then have the system retry the input. 
When semantic information is being considered. Users 
may ask to examine or modify current definitions of 
prepositional phrases, verb phrases that take "up" as a 
particle, and so forth. To do so, the user first specifies 
the syntactic relationships of the phrases of interest. 
As shown below, the manner in which the user specifies 
a phrase or range of phrases is independent of the 
reason the case frame information is being sought. 
4. Principles Behind Case Frame Specifications 
The primary criteria our methods of case frame 
specification are designed to meet are: 
To be independent of the specific NLP that information is 
being supplied to. This permits us to alter or augment 
the underlying case frames used by the parser without 
having to change any of the actual code responsible for 
acquiring phrasal compatibilities from the user. For 
instance, we have made several changes in the way 
relational nouns like "classmate" are processed, without 
any changes to the customization modules. 
To be fully data-driven. Our knowledge acquisition 
modules provide general capabilities for a large class of 
phrase types, but they know nothing specific about verb 
phrases, etc. This is our principal method of achieving 
the previous criterion. At present, about two pages of 
specifications of a form shown below are used to drive 
TELI'a knowledge acquisition component. 
To be driven by data which can in principal be inferred 
from the underlying grammar. This means that any 
changes to the grammar will be automatically reflected 
in the modules that acquire case frame information. At 
present, about half of the two pages of data that drive 
our syntactic knowledge acquisition module are taken 
directly from the grammar. 
In addition to the above criteria, which relate to 
automating the process of customizing an NLP, an 
additional human factors criterion is to have types of 
455 
information which function similarly, from the user's 
standpoint, appear similar as presented by the system. 
Thus, output formats do not always reflect how 
information is stored and manipulated by the system. 
5. Defining the User Interface to Case Frames 
At present, TELI provides for five phrase types: 
Adjective Phrase: 
e.g. researchers associated with TEL1 
Noun-Modifier Phrase: 
e.g. the COLING presentations 
Verb Phrase: 
e.g. employees working with Brachman 
Prepositional Phrase: 
e.g. the researchers in Marcus' department 
Relational Noun Phrase: 
e.g. the associates of Litman, 
the salary of Smith 
In discussing how actual case frame acquisitions are 
done, we wilt find it convenient to give in detail all the 
information associated with one of the phrase types 
provided for by the system grammar. For this purpose, 
we have chosen to consider adjective phrases, since the 
situations they involve are fairly representative. The 
actual system provides somewhat more sophisticated 
capabilities than what we have space to describe here, 
especially in its treatment of verb phrases. 
Before proceeding, we note that the actual data 
structures used in TELl differ slightly from those 
presented here, although they contain precisely the same 
information. Also, we mention that our use of the term 
"interface designer" reflects our belief that most of the 
job about to be described can be done by a trained user 
of the system, as opposed to the actual system builders. 
Before TELI is supplied with phrase type 
information, it will have been given lexical information 
about each part of speech recognized by the underlying 
grammar. Parts of speech are also classified as either 
"open" or "closed", the former enabling the user to 
supply new words of that type. For example, the system 
designer might have specified 
Open (adjective, noun, verb .... ) 
Closed = (article, prep, ...) 
This information is used by the acquisition module in 
deciding which case frame slots may be filled with 
vocabulary items not already in the system lexicon. 
As a first step in telling the system about phrase 
types, the interface designer must indicate for each case 
frame slot (1) a name to be used inside the system to 
identify this slot, (2) an appropriate filler type, and (3) 
an external name to be used as a label in system output. 
For adjective phrases this might be given as 
456 
(adjinfo 
(head entity "Subject") 
(adj adjective "Adjective") 
(prep prep "Preposition") 
(obj entity "Object")) 
where "adjinfo" is an arbitrary symbol used internally to 
reference adjective phrase case frames. Slot names 
(head, adj, prep, obj) are arbitrary; filler types (entity, 
adj, prep) generally correspond to parts of speech, 
although "entity" denotes the subset of nouns that 
comprise the primitive object types of the domain at 
hand. For example, in a building domain, Room might 
be a basic object type (entity), while "office" is merely a 
noun that refers to some of the objects of type Room. 
Finally, extenTal names ("Subject" etc.) may be any 
string useful in identifying a case role. 
Next, the interface designer specifies an arbitrary 
number of templates which the system will seek to 
match against a user's English-like case frame 
specification. For example, 
(adjinfo (a Head can be Adj Prep an Obj)) 
enables the system to recognize a specification such as 
"a room can be adjacent to a corridor" 
as a reference to an adjective phrase case frame. Recall 
that this information is given by the interface designer 
and does not define, but merely reflects, the 
grammatical coverage provided by the underlying 
parser. Note that case frame templates are specified in 
terms of case frame labels rather than parts of speech. 
This allows transposing the etements of a case frame 
containing two or more elements of the same type. 
In the event that the interface designer wishes to 
specify optional items, (s)he can either give multiple 
specifications or denote optionality within parentheses. 
Thus, the verb phrase specification 
(subj verb (obj) (part) (prep obj)) 
will expand into eight patterns having from two to six 
elements each. 
Since the interface designer will have specified 
slot names for each type of case frame, the system can 
easily detect the presence of "noise" words. In addition, 
small matters such as the equivalence of "a" and "an" 
must be taken care of, and the interface designer does 
this be a giving a translation map such as 
Noise-Translations = ((an a) (the a)) 
which instructs the system to make the indicted 
replacements in both an English-like specification to be 
matched and the internal patterns. It is not necessary 
that all noise words be present in the system dictionary. 
For example, "can" does not presently appear in the 
context of our question-answering applications. 
6. A User's View of Case Frame Specification 
There are two ways in which a user may designate 
which case frame information is of interest, namely (1) 
by menu, and (2) by English-like specification. The 
former is straightforward, while the latter is more 
convenient, and more interesting. 
In specification by menu, the user first indicates a 
phrase type to be inquired about, and is then instructed 
by the system to provide a filler for each slot in the 
associated case frames. For example, to find out what 
domain objects can be "in" a county, a user would make 
the selections indicated in Figure 2. Since our case 
frames allow both the head-noun and argument-of- 
preposition slots to be filled with any basic object type 
of the domain at hand, the second and fourth menus 
contain the same options. The internal list that results 
from these specifications is essentially 
Phrase Type: Prepositional Phrase 
Head Noun: (all) 
Preposition: in 
Object: county 
As suggested in Figure 2, during menu specification, the 
system considers in turn each case slot of the phrase 
type in question and, for each of them, presents to the 
user for selection a list of current fillers, along with an 
option to "look at all". For slots whose filler type is 
either an open category, or a closed category having 
possible fillers not presently being listed, an option to 
select some "other" filler is included. Finally, for 
optional phrase elements (e.g. direct object of a vcrb), 
an option appears that allows the user to select "nonc". 
In English-like spccification, the user typcs a 
phrase that indicates each desired slot value, not 
necessarily in the order they appear in internally. 
Appropriate noise words may appear, and "?" may be 
used as a "wildcard" to indicate an interest in all 
possible values. For example, the sample specification 
given above by menu could be indicated by 
"a ? can be in a county" 
As with menu specification, it is possible for the user to 
introduce new vocabulary. For instance, if the italicized 
items Were new in the specifications 
"an employee can report to a manager" 
"an employee can be rerponsible for a project" 
"an employee can be the supervisor of a project" 
the system would have sufficient information to find a 
unique match among the patterns stored. In these 
situations, the system will have automatically 
determined the part of speech of the new word. 
Although our use of "?" may seem artificial in the 
example above, when compared against a more fluent 
method of inquiry such as "what can be in a county", it 
allows any case frame slot to be inspected, not just those 
slots that are filled with nominals. For example, a user 
might specify 
"a city can be ? a county" 
to find ali prepositions linking "city" with "county", or 
"an employee can ? a project ?" 
to find all verb-particle pairs connecting "employee" 
with "project". We prefer to provide a small number of 
simple and powerful mechanisms, even though other 
methods might appear preferable in some situations. 
For the readcr whose aesthetics clif\[cr from ours, we 
note that alternate phrasings can bc provided for by 
simple modifications to the algorithm given in Section 7. 
Unlike menu specification, English-like 
specification allows certain ambiguities to arise, 
especially when the system designer has chosen to 
permit terse forms with few or no noise words. For 
example, the respective absence of the noise words "can" 
and "can be" in the specifications 
"employee responsible for project" 
"employee report to manager" 
makes it impossible for the system to decidc whether the 
new word is an adjectivc or a verb. In such situations, 
Examine Inf'o for Some: 
Adjective Phrase 
Noun-l%difier Phrase 
-l..--Pr-epositional Phr'a >e 
Verb I~ hra'_=.e 
Fur, ctionat Noun Phrasr:. 
.......................... 
Look exhau~.t.iveJy at .... 
========================= 
\[ ret.urrl \] 
Head Noun 
(of" Prep Phrase) 
,ADDRESS 
CITY 
COUNTY 
FOOD 
PHOHE 
RES T,'~UR,qI'.IT 
-D---(all of these) 
(,qbort!) 
Preposition 
(of" Prep Phrase) 
\[ So far: (all) ... \] 
IN 
WIltl 
(other) 
(tlbor t!) 
Ar(jtlment of Preposition 
(of Prep Phrase) 
\[ So ram (all) IIq ... \] 
,qOORESS 
CITY 
-----------.,-~ C OUIqT Y 
FDOD 
PHONE 
REST4UF.,'Ar',IT 
.............................. 
(all of t,k, cs,:) 
(,qt:,ort b 
Figure 2: Menu Requests to See What Objects Can Be "in" a "county" 
457 
the system constructs a suitable menu, which for the 
above specifications would be roughly 
What type of information are you (livinq? 
- t)erb Phra-~Pat't i ci e --- 
gt"dinarv 9e:rb Pt-,ras:e 
¢hdject.ive Phrase 
.................. -(F;F;7-,-s- ................ 
In the other extreme, it is possible that none of the 
stored patterns match the user's specification, in which 
case the system requires the user either to paraphrase or 
to resort to menu specification. 
In our experience, English-like specification 
yields a unique match about 80 percent of the time; 
more than one match about 15 percent of the time; and 
no matches about 5 percent of the time. The most 
frequent situation in which a multiple match occurs 
concerns the possibility that a preposition appearing in a 
verb phrase is a particle. For example, if the user types 
"an employee can pick a project up" 
then "up" is known to be a particle by its position• If 
instead the user were to type 
"an employee can pick up a project" 
then the system will need to determine whether "up" is a 
particle. Although we generally aw)id yes-no questions, 
as discussed below, we decided to allow one in this 
frequent and predictable situation, as indicated by 
I Can 
an employee can work for a manager 
be paraphrased as 
an em~ e.V~e_can wot'k a m~(or 
--\[ -- "( ~: :5, 
.......... .................... 
Finally, it is useful to allow the system to present 
the user with relevant information that the system 
knows it will need, rather than wait (and hope) for the 
user to offer it. As a first example, suppose the system 
has failed to parse the input 
"Which corridor is Stumberger's office adjacent to'?" 
and the user accepts tile system's offer to provide help 
in tracking down the problem. Since the word 
"adjacent" is an adjective, and adjectives are known to 
have phrases associated with them, the system will 
supply all current information about those adjective 
phrases having "adjacent" in the adj slot and leaving tile 
remaining slots unspecified. That is, the system will 
respond as though the user has specified 
Phrase Type: Adjective Phrase 
Head Noun: (all) 
Adjective: adjacent 
Preposition: (all) 
Object: (all) 
458 
7. How English-Like Specifications are Processed 
When an English-Like Specification is received 
from the user, the system must (1) determine what 
phrase type is being dealt with; (2) detect any new 
words; and (3) account for any unspecified (wildcard) 
case slots. As an example, suppose a user wants to know 
what things can be "associated with" an employee, and 
suppose further that the word "associated" is not yet 
known to the system. In this case, the system will 
naturally know of nothing that can be "associated with" 
an employee, but will give the user an opportunity to 
add to its knowledge. If tile user were to type 
an employee can be associated with a ? 
this specification is first is scanned and turned into 
a employee can be ?? with a ? 
where "??" marks the position of all unknown word and 
"'~" continues to denote a wildcard slot. Note that (1) a 
"noise translation" from Section 5 has been used for 
"an", and (2) the noise words "can" and "be" have not yet 
been removed, since they may act as content words in a 
pattern for something ()tiler than an adjective phrase. 
The next step is to substitute part-of-speech labels 
for each word in the partially processed specification. 
Only those parts of speech that tile system knows are 
relevant, as indicated by the information supplied by the 
interface designer as shown above, are included (e.g. %" 
is not replaced by "article"). Thus, tile system converts 
tile structure shown above into 
a (noun entity) can be ?? (prep) a ? 
• at which point an attempt can be made to match tile 
internal patterns that represent the acceptable case 
frame specifications. 
The pattern matching that occurs at this point is 
simple, where 
? matches any case slot 
?? matches any "open" category case slot 
x matches x 
(x y ...) matches any of x, y .... 
In particular, the single match found for the structure 
shown above is 
a entity can be adj prep a entity 
which is known to be associated with adjective phrases 
(since it was defined for that purpose). 
At this point, the intermediate structure 
containing the ?? marker is re-examined and compared 
with the original specification the user typed; the user is 
asked to confirm that "associated" is indeed a new 
adjective; and the lexicon update routine is invoked to 
insert "associated" into the lexicon as an adjective. 
Next, the system strips noise words and so the case 
frames to be examined are indicated by 
Phrase Type: Adjective Phrase 
Head Noun: employee 
Adjective: associated 
Preposition: with 
Object: (all) 
Finally, the system presents a l-dimensional mentt, 
similar to that shown below in Figurc 3b, which allows 
the user to specify what things an employee can be 
associated with. 
8, Display of Relevant hfformation 
The formats that we have chosen for TELl to 
display the current case frame iuformation relevant to a 
user's specification are based on the desires 
I. to allow information to bc inspected and updated 
simultaneously, and 
2. to minimize the number of specific menu t y/)es 
presented to the user. 
In particular, thc system constucts, whenever possible, a 
menu in which each possible setting of unspecified case 
frame values may independently be turned "on" or "off" 
by a mouse click. In the current implementation, 
"whenever possible" amounts to precisely those 
situations in which no more than two case frame slots 
are left unspecified. Thus, a menu will contain choice 
boxes which have from zero through two dimensions, 
according to the number of unspecified case slots. 
Examples appear in Figures 3a through 3c. Note that 
appropriate row and column labels, and also a suitable 
menu label, must be constructed by the system. Since 
the system has no initial domain-specific vocabulary, 
these menus must be formulated at run-time. 
When more than two case slots are unspecified, 
the system simply prints all existing case frames that 
satisfy the indicated constraints, supplying an initially 
filled box for each, as indicated in Figure 3d. This 
allows the user to remove individual case frames, and 
the "Add" oplion allows information to be added. 
Although we have chosen to avoid asking literal 
yes-no questions whenever possible, largely because of 
the low information content they provide, the choice- 
box scheme we have adopted implicitly asks a number of 
simultaneous yes-no questions. Thus, when the user 
checks the box in a menu for the preposition "with" 
having City as row label and County as column label, 
(s)he is in effect answering "yes" to the implicit question 
"can a city be in a county". 
9. Discussion 
We now consider (a) treatment of single-word 
modifiers, (b) phmned enhancements to case frame 
capabilities, and (c) related acquisition modules. 
i t i c,,,.~ 1D Pl-,r ..... E M F'L,-,',' Upd.dt_ e EE IltO DE F'FIR 1 r'IEItT \[\] !11 
\[_Pr~d;,,D~iglo,-,al Ph, ~seLEMP_LOYEE IH : _ 
IDEPARTrlEHT \[\] 
IEI'IPLOYEE \[\] IrlaHnGER \[\] 
I IDFFICE 
I_PPOJ_ECT .... u 
\[E,<it \[\] Update \[\] 
F~lEPRPfl. EIIT {'!',-k':~l ~ i'~t-'! -\[!!!: -'#i" L \] Ill :r I;E!:'QST!'!\[\[\] H\[ EI!F!\[\]I'I'I \[\[i ~:~)! \[t IE;~F~ Qf(\[l\[\] F FFF,\[\]I~\[ I 
IE r-if:It I:,,'F f N O \[\] N \[\] I 
Im,.*,l ~ N \[\] \[\] El \[\] I F,F~I, I \[\] \[\] \[\] \[\] \[\] I 
Ir~:~'YEc! N ~ \[\] \[\] O I F: !' ~ 'UP t' q l 
~o:--,i t i on.-~ l F'hca-~e : 
DEPARIPIEIIT IdlTII llfltlfli~EF,' 
EI'IPLUYEE III DEPAPII'IEHI 
IEMPLOYEE IN OFFICE 
EMF'I.O','EE I.lI1H DEPRRIIIEItT 
zfIPLOYEE I.tITH nFFIF:E 
-IIPLOYEE MITH PPOHEH1 
"IRHHGEF~' IIt \[IEF'RRHIEHI 
3RO._IECT IIt DEF'RF'rI'IEItT 
qdd \[\] leet,,,-n \[\] 
\[\] \[\] 
\[\] \[\] 
\[\] \[\] 
N N 
Figure 3: Case Frame Display for Varying 
Number of Queried Slots 
The techniques presented in this paper, ~hich arc 
directed toward case frames for multiple-word phrases, 
are actually used for single-word modifiers as well. 
Internally, one important difference is that the 
associated modifier compatibility information is 
maintained in the lexicon rather than stored into 
auxiliary case frames. A'~ an example, if the user says 
that the word "large" can modif 3 obiccts of type 
Department and Office, onc associated lcxical entry is 
(larger compar large (nt department office)) 
As with case lramcs, the user may impart compadbilit> 
information for single-word modifiers by either menu or 
English-like specification. Fhe latter is typified by 
a room can be large 
while an example of how the user may ask to see 
everything known about acceptable adjective 
modifications is shown in Figure 4. 
Several enhancements to our facilities for 
Englishqike capabilitites are planned. For instance, we 
noted in section 6 that whereas the use of "?" to denote 
an unspecified slot works for all parts of speech, it 
might be more natural to denote unspecified norms by 
EX.PEHSI UE \[\] \[\] 
QUIET rl \[\] :~r'Ic)' _N \[\] 
E>Ht \[\] U\[\],JL\]te \[\] 
Figure 4: Modifier Information for Adjectives 
459 
"w\[aat" and possibly transpose the specification 
accordingly. As noted previously, the question is one of 
generality versus naturalness in specific situations; 
simple modifications to the algorithm given in the 
preceding section would enable alternate forms. We are 
considering whether to alter our methods of inquiry, 
perhaps to provide for both forms. Another 
enhancement being considered is to permit inflected 
forms, as indicated by the italicized elements of 
students can be failed by an instructor 
Finally, we wish to give some feeling for the 
lexical and semantic acquisition facilities alluded to in 
the paper. Figure 4a gives the top-level menu pertaining 
to part-of-speech information. This menu enables the 
user to obtain output which as with case frame 
information allows simultaneous inspection and 
modification, as illustrated in Figure 4c. Word and 
phrase meanings are acquired similarly, and also involve 
either menu or English-like specification. As an 
example of the latter, if the user has said that 
an employee can work with an employee 
then the system will ask what "work with" means in this 
sense by selecting two example employees in terms of 
which the user is asked to define semantics. For 
example, the system will in effect ask 
What does it mean for Bob to work with Jill? 
at which point the user might say 
the dept of Bob is equal to the dept of Jill 
10, Related Work 
Some of the systems which, like TELI, seek to 
provide for user customization within the context of 
database query are ASK (Thompson and Thompson 
1983, 1985), formerly REL (Thompson and Thompson, 
1975), from Caltech; INTELLECT, formerly Robot 
(Harris, 1977), marketed by Artificial Intelligence 
Corporation; IRUS (Bates and Bobrow, 1983; Bates, 
Moser, and Stallard 1984), from BBN Laboratories; TQA 
(Damerau, 1985), formerly REQUEST (Plath, 1976), 
from IBM Yorktown Heights; TEAM (Martin et al, 
1983; Grosz et al, 1985), from SRI International; and 
USL (Lehmann, 1978), from IBM Heidleberg. Other 
high-quality domain-independent systems include 
DATALOG (Hafner and Godden, 1985), from General 
Motors Research Labs; ItAM-ANS (Hoeppner et at, 
1983; Wahlster, 1984), from the University of Hamburg; 
and PttLIQA (Bronnenberg et al, 1978-1.979), from 
Philips Research. 
Due to the space limitations endemic to 
conference papers, we refer the reader to Ballard and 
Stumberger (1986) for some substantive comparisons, 
largely related to semantic issues, between TELl and 
each of TEAM, IRUS, TQA, and ASK. 
460 

References 

Ballard, B. A "Domain Class" Approach to Transportable Natural 
Language Processing. Cognition and Brain Theory 5, 3 (1982), 
269-287. 

Ballard, B. The Syntax and Semantics of User-Defined Modifiers in 
a Transportable Natural Language Processor. Proc. Coling-84, 
Stanford University, July 1984.52-56. 

Ballard, B., Lusth, J.. and Tinkham, N. LDC-I: A Transportable 
Natural Language Processor for Office Environments. ACM 
l'rcmsactions oll Office Information S3'stem.~ 2. 1 (1984), 1-23, 

Ballard, B. and Stumberber, D. Semantic Acquisition in TELl: A 
Transportable, User-Customized Natural Language Processor. 
Proc. 24th Annual Meeting oj" the ACL, Columbia University. 
June 1986. 

Ballard, B. and Tinkham, N. A Phrase-Structured Grammatical 
Framework for Transportable Natural Language Processing. 
Computational Linguistics 10, 2 (1984), 81-96, 

Bates, M. and Bobrow, R. A Transportable Natural Language 
Interface for Information Retrieval, 6th Int. ACM SIGIR 
Conference, Washington. D.C,, June 1983. 

Bates, M.. Moser, M. and Stallard. D. The IRUS Transportable 
Natural Language \[nterface. Proc. First Int. Workshop on 
Erpert Database Systems, Kiawah Island, October 1984. 

Bronnenberg, W., Landsbergen. S., 8cha, R.. Schoenmakers, W. 
and van Uttcren. E. PHLIQA-I.a Question-Answering System 
for Data-Base Consnltatioa in Natural English. Philips tech. 
Rev. 38(1978-79),229-239and269-284. 

Damerau, F. Problems and Some Solutions in Customization of 
Natural Language Database Front Ends. ACM Transactions on 
Office Information Systems 3, 2 (1985). 165-184. 

Grosz. B.. Appelt, D., Martin, P. and Pereira, F. TEAM: An 
Experiment in the Design of Transpartable Natural-Language 
Intrfaces. Artificial Intelligence, to appear. 

Hafner, C. and Godden, C. Portability of Syntax and Semantics in 
Datalog. ACM Transactions on Office Information Systems 3, 2 
(1985). 141-164. 

Harris, L. User-Oriented Database Query with the ROBOT 
Natural Language System. lnt. Journal of Man.Machine Studies 
9 (1977), 697-713. 

Hoeppner, W., Christaller. T., Marburger, H., Morik, D., Nebel. B., 
O'Leary, M., and Wahlster. W. Beyond Domain-Independence: 
Experience with the Develapment of a German Language 
Access System to Highly Diverse Background Systems. Proc. 
8th lnt. J. Conf. on Artificial Intelligence, Karlsruhe. West 
Germany, 1983, pp. 588-594. 

Johnson, T. Natural Language Conlputing, The Commercial 
Applications, Ovum ktd. London. 1985. 

Lehmann, H. Interpretation of natural language in an information 
system, lBM J. Res. Dev. 22.5(1978).pp. 560-571. 

Martin, P.. Appelt, D. and Pereira, F. Transportability and 
Generality in a Natural Language Interface System, Proc. 8th 
Int. J. Cot(. on Artificial Intelligence, Karlsruhe. West 
Germany, 1983, pp, 573-581. 

Moser, M. Domain Independent Semantic Acquisition. BBN 
Report No. 5694, Research in Knowledge Representation for 
Natural Language Understanding, September 1984, 

Thompson, F. and Thompson, B, Practical Natural Language 
Processing: The REL System as Prototype. In Advances in 
Computers, Vol, 3. M. Rubinoff and M. Yovits, Eds., Academic 
Press, 1975. 

Thompson, B, and Thompson. F. Introducing ASK: A Simple 
Knowledgeable System, Conf. on Applied Natural Language 
Processing, Santa Monica, 1983. 17-24. 

Thompson. B. and Thompson, F. ASK Is Transportable in Half a 
Dozen Ways. ACM Trans, on Office Information Systems 3, 2 
(1985). 185-203. 

Wahlster. W. User Modets in Dialog Systems, Invited talk at 
CoitaL-a4, Stanford University, July 1984, 
