Semantic Caseframe Parsing and Syntactic Generality 
Philip J. Hayes. Peggy M. Andersen. and Scott Safier 
Carnegie Group Incorporated 
Commerce Court at Station Square 
Pittsburgi'~. PA 15219 USA 
Abstract 
We nave implemented a restricted .:lommn parser called 
Plume "M Building on previous work at Carneg=e-Mellon 
Unfvers=ty e.g. \[4, 5. 81. Plume s approacn to oars=ng ~s 
based on semantic caseframe mstant~a~on Th~s nas the 
advantages of effic=ency on grin ~atical ,nput. and 
robustness in the face of ungrammatmcal tnput Wh~le Plume 
~s well adapted to s=mpte ,:;~ectaratwe and ~mperat=ve 
utterances, it handles 0ass=yes relatmve clauses anti 
=nterrogatives in an act noc manner leading to patciny 
syntact=c coverage Th~s paOe, oulhnes Plume as =t 
Currently exfsts and descr,Oes our detaded des=gn for 
extending Plume to handle passives rela|~ve clauses, and 
=nterrogatlves ~n a general manner 
1 The Plume Parser 
Recent work at Carnegie-Mellon Umvers=ly eg. \[4. 51 has 
sinown semanttc caseframe =nstant~ation to be a n,ghly robust 
and efficient method of parsing restricted domain ~n0ut. In 
tn~S approach ~0 parsing, a caseframe grammar contains lhe 
doma~n-soecific semantic informat=on, ana" the pars=ng 
program contains general syntact=c knowledge Input ,s 
mapped onto me grammar using m=s budt-~n syntact=c 
knowledge We nave chosen m=s approach for Plume ":'M a 
commercial restricted domam parser ~ because of ~ts 
advantages =n efficfency and robustness 
Let us take a simple example from a natural language 
interface, called NLVMS. thai we are developing under a 
1 More 0:eccselv. Phjme TM ,s me n4me ,)t lne run-hltle ~vstem 
TM assoclalecl N~m Language Craft an mlegralerJ envlrollmenl for me 
oevetoomenl of naluraI language ,nteHaces "he PlUm? 10arser Nnlch 
transla{es Eng#lsl'l lil~UI qnto casetrame ,nslances, .s a malot comDoneiIt 
ot tt~=s rurl-tlme system The diner malOr -,3111OG~te~H tratislales ire 
caseframe ~nslance~ into aoDIica|lofl specifIC !anguaqes. in JlOOlhon to 
the Plume run-brae system, ta.guaqe Craft ,nc!uoes grammar 
development ~OOlS ,ncludlng -.1 -;lrH,:hJreO edllOr .ln~l tracing ,1ha 
,~ert.3rmance rneasutemenl rOi)~S ~r~ln Plume Ji~a ~Jltq,iaqe Craft ate 
crOOuctS ,It Carnegie Group .~.d ,Jle u,telltly i,I re'~lrlrleO r~tease 
Plume .\]n~ Language CI,Ift It@ ,,,Id~,,Idr v'~ ,',t \]ot.1.+gle :3~,)HO 
'ncotoorafe~l 
contract with Digital Equipment Corporation NLVMS ,s an 
tnterface to Digltal's VMS ~ operating system for './AX ~ 
computers 2 The Plume grammar for .th~s ,ntertace contains 
the follow=ng semantic caseframe 3 correspond=ng ¢o the copy 
command of VMS: 
\[ *copy* 
:cf-type clausal 
:header copy 
:cases 
( f i le-to-copy 
:filler *file* 
:positional Direct-Object) 
( source 
:filler *directory* 
:marker from I out of) 
(destination 
:filler *file* I *directory* 
:marker to I into I in l onto) \] 
This defines a caseframe called "copy" w~th mree cases: 
file-to-copy, source, and destination The hie-to-copy case ,s 
filled by an oioiect of type "file" and appears =n the input 
as a direct oblect Source ,s filled 0y a "d~rectory" and 
should appear in me ~nput as a preposmonal phrase 
preceded or marked by the prepos,t~ons "from" or 'out of" 
Oestinat=on is filled by a "file" or "clirectory" and ~s marked 
by "to'. "into'. or "onto" Finally the copy command itself 
is recognized by the header word ,ndicated above (by 
header) as "copy" 
Using mis caseframe. Plume can parse ,n0uts like: 
Copy fop Oar out ot \[x/ ,nro \[y~ 
From \[x\] to \[yJ cooy fop oar 
too oar coDy /rom \[x/ ro \[y/ 
2VMS anO VAX are ¢raOemark5 of Olg=tal EQu.omen! CorDorallon 
\]Th.s is a s.npiltleO .:e,slols ,~t rne r.L~e,, ~.~ e .I..'~,.IIh/ ~ fne gralnmar. 
153 
In essence. Plume's parsing algorithm +S tO find a caseframe 
header, in this case "copy" and use the associated 
caseframe, "copy" to guide the rest of the parse. Once 
the caseframe has been identified Plume looks for case 
markers, and then parses the associated case filler directly 
following the marker Plume also tnes to parse pomtionally 
specified cases, like direct ObleCt. in the usual position in 
the sentence - immediately following the header for direct 
object. Any input not accounted for at the end of this 
procedure is matched against any unfilled cases, so that 
cases that are supposed to be marked can be recognized 
without their markers and pos=tionally indicated cases can be 
recognized out of their usual positions, This flemble. 
interpretive style of matching caseframes against the input 
allows Plume to deal with the kind of variation in word order 
illustrated in the examples above. 
The above examples implied there was some method to 
recognize files and directones They showed only atomic 
file and directory descriptions, but Plume can also deal with 
more complex ObleCt descnptions In fact, in Plume 
grammars, obiects as well as actions can be described by 
caseframes. For instance, here =s the caseframe s used to 
define a file for NLVMS 
\[*f~le* 
:.c f- type nominal 
:header file ' 
:name ?(%period ~extension) 
: cases 
( name 
: assignedp t name) 
( extension 
: assignedp t extension 
:marker written in 
:adjective <language> 
:filler <language>) 
(creator 
:filler *person* 
:marker created by) 
(directory 
:filler *directory* 
:marker in) \] 
4 n rme syntax used ,.',,.n VMS. chrectorles are ,ncl.calecl Dy sauare 
Dtackefs. 
5~qa~,~ ~,mOl,hed 
~l~lUtl~e ,.\]ulOmall< allv +e,:oqn,zes "l~.te,mmer ¢, 4rl,1 :lual~hl,er~; asSoclaled 
• .,fn ~totnmal , a~|f'~tf~e5 
This caseframe allows Plume to recogn,ze file descriptions 
like: 6 
fop 
fop.Par 
The file created Oy John 
The fortran file in ix/ created Oy Joan 
The caseframe notation and parsing algorithm used here are 
very similar to those described above for clause level input. 
The significant differences are additions related to the 
:adiective and :assignedp attributes of some of the cases 
above. While Plume normally only looks for fillers after the 
header in nominal caseframes an adiective attnbute of a 
slot tells Plume that the SlOt filletmay appear before the 
header. 
An :assignedp attribute allows cases to be filled through 
recognition of a header+ This is generally useful for proper 
names, such as fop and foo.bar. In the example above. 
the second alternatwe header contmns two '.,ar~ables name 
and 'extension. that can each match any s=ngJe .vorcI. The 
ClUeSt=on mark Indicates opt=onal~ty, so that me header can 
be either a single word or a word followed Dv a per=pal and 
another word. The first wOrd ,s asmgned to the ~'anaOle 
'name. and IRe second (if =t =s mere~ to the vanaOle 
!extension If 'name or 'extension are matched ,,vnde 
recognizing a file header, their values are placed ,n the 
name and extenmon cases of "hie" 
w,ln the above mod,ficat,ons P~ume can parse nomqna, 
caseframes umng the same algor~ttnm that ~t uses for clausal 
caseframes that account for complete sentences. However 
there are some interactions between the two levels of 
parsing. In particular, mere can be ambiguity about where 
to attach marked cases• For anstance. In: 
Copy me fortran file ,n \[,:/ to \[y/ 
"~n \[xr" could e,her fill the directory case of the hie 
described as 'the fortran hie or could fill the dest+natBon 
case of the whole copy command. The second 
interpretation does not work at the global level because the 
only place to put "to \[y}" ,s tn that same destination case 
However. at the time the file descrlpt,on ts parsed, tins 
information is not avadable and so both possible 
attachments must be considered In general, if Plume is 
able to fill a case of a nora,hal caseframe from a 
154 
prepositional phrase, it also splits off an alternative parse in 
which that attachment is not made. When all input has 
I~een parsed. Plume retains only t~ose parses t~at succeed 
at the global level, i.e.. consume all of the input. Others 
are discarded. 
The current implementation of Plume is based on the 
nominal and clausal level caseframe instant=ation algorithms 
descnPed above. Us=ng these algor=thms and a restr=cted 
clommn grammar of caseframes like the ones ShOWn above. 
Plume can parse a w~de variety of ~mDerat~ve and 
declarative sentences relevant to that doma=n. However. 
there remain significant gaps ,n ~ts coverage. Interrogatives 
are not handled at all: + passives are covered only if mey 
are explicitly specified =n the grammar ancl relative clauses 
can only be handled by pretending they are a form of 
prepos=t=onal phrase 
The regular and predictable relattonsn~p between s~mple 
statements. ¢~uestions and relalwe clauses and between 
act=ve and passive sentences ~s ,veil known A parser wmcil 
purports to tnterpret a dohlaln specific tanguage specification 
using a built-in knowledge of symax ShOuld account for tills 
regularity =n a general way The current implementer=on of 
Plume ilas no mecnamsm for doing tn~s. Eacil ~ndividual 
possiDdity for questions relative clauses and passives must 
be explicitly specified ,n the grammar For instance, to 
handle reduced relative clauses as =n "the file created by 
jim .... created by" ~s hSted as a case marker (compound 
prepositlorll tn the creator slot of file. mark+ng a description 
of the creator To handle full relat=ves the case marker 
must be specified as something hke "3(which < be >) 
created by". '3 Wh=ie mis allows Plume to recognize +the file 
which was created by Jim", "the file created by Jim". or 
even "the file created by Jim on Mondav ~t breaks down 
on something like "the file created on Monday by Jim ' 
because the case marker "created by' {s no longer a unll 
Moreover using the current techniques. Plume S abdtly to 
?rhR Curren! ,rnoleftl~nt;~llon ,)1 PIIIIII@ ".* a }s -.~ lef/l~,) r,~tV t'nF, iI'l,)d OI 
,, ,I ,.aseft,)me 
,, 1 .-. ~ .t i11 la ii ,-~ ~1 
recognize the above inputs =s completely unrelated tO =ts 
abdity tO recognize inputs like: 
the fi/e Jim created on Mon(Tay 
the person that the file was crearect ov on Monday 
the day on which Jim created rne me 
If an interface could recogmze any of these examptes +t 
might seem unreasonable to a uSer that ~t could not 
recognize all of the others Moreover g~ven any of the 
above examples, a user might reasonaPly expect recogmt=on 
of related sentence level inputs hke 
Create the hie on Monday' 
J~m created the hie on Monday 
Dt~ J~m create the hie on Moneay ? 
Was the hie create(l Ioy J~m on Monclay ~ 
Who created the hie on Monday ? 
What day was the hie created on? 
The current ,mplememation of Plume has no means of 
guaranteeing such regularity of coverage. Of course, this 
problem of patcl~y syntactic coverage is not new for 
restricted doma=n parsers. The lack Of syntactic generality 
of the original semantic grammar {3\] for the Sophie system 
{21 led tO the concept of cascaded ATNs {10} and the 
RUS parser {1 I, A progress=on w=tln s=milar goals occurred 
from the LIFER system \[91 to TEAM {6\] and KLAUS \[7\]. 
The bas=c oDstacle to ach~evmg Syntactic generality ~n 
these network-based approaches was me way syntactic and 
semantic information was m=xed together +n the grammar 
networks. The sOlutions, therefore, rested on separating the 
syntact=c and semanttc reformat=on. Plume already 
incorporates just me separation of syntax and semantics 
necessary for syntactic generahly general syntactic 
knowledge resides in the parser whde semantic =nformat=on 
resides ~n the grammar This suggests that syntactic 
generahty ~n a System like Plume can be acnreved Qv 
,morowng the parser s caseframe ,nstanttatJon algOrithms 
.vHnou{ 3n~,. malor changes to arammar Content ,n terms of 
me above examples =nvo~wng ;reafe =t suggests .."Je can 
use a s4ngle "create" ,,:3seframe to nandte .~11 the examples 
We Simply need to prowde suHable extensions to the 
existing caseframe nslantlatton algoNthms In the next 
section we present a detaded deszgn for such extensaons 
2. Providing Plume wtth Syntactic Generality 
As descr=bed above. Plume can currently use clausal 
155 
caseframes only to recognize s,ngle clause imperative and 
declaratwe utterances in the active voice. This section 
describes our design for extending Plume so that relative 
and interrogative uses of clausal caseframes in passive as 
well as active voice can also De recognized from the same 
information. 
We will present our general design by showing how it 
operates for the following "create" caseframe in the context 
of NLVMS 
\[ *create* 
: cf-type clausal 
:header <create> 
: cases 
(creator 
:filler *person* 
:positional Subject) 
(createe 
:filler *file* 
:positional Direct-Object) 
(creat ion-date 
:filler *date* 
:marker on) \] 
Note tNat symbols in angle brackets represent non-terminals 
,n a conmxt-free grammar (recogmzed by Plume using 
oattern matching techn,ques) In Ine caseframe defin,tlon 
above <create> matches all morDnologlcal vat=ants of the 
verio 'create" ,ncluding "create ' 'creates ' 'created" and 
'creating" impugn not combound tenses +~ke .s :real,ng' 
see below). Using me ex,st=ng Plume :n,s .':ouid 3olv 9.1lOW 
uS tO recognize simple ~mperallves and actwe ~eclarat,ves 
llke 
Create ~oo Oar on Moniaav 
2m crealecI tot)oar on Mor~Uay 
2. I Passives 
Plume recogn,zes pasture sentences lhrough ~tS processing 
of the \]erO cluster +e the ma~n verb plus me sequence of 
modal and auxiliary .'erD ,mmedlalely preceding it. Once 
me main verb has been located a sl0ecsal verb cluster 
processing mechanvsm reads me verb cluster and determines 
from il whether me sentence ts acttve or passive 'j The 
parser records tills =nformaticn in a special case called 
"%voice". 
If a sentence is found to be achve the standard parsing 
algor,hm described above ,s used If =t is found to be 
passive, the standard algorithm ~s used with the modification 
that the parser looks for the direct object or the indirect 
object ~° in the subject positron, and for the subject as an 
optional marked case with the case marker "by". Thus. 
given the "create" caseframe above, the follow,rig passive 
sentences could be handled as well as their active 
counterparts. 
Fop oar was creamd by Jim 
FOO oar COuto /'lave dee t~ rFateo ov j,m 
FO0 oar ,s Oe,ng (reate~l ~v ~,m 
Fop Oar was created on MGnclay 
22. Relative clauses 
The detailed design presented below allows Plume to use 
the "create" caseframe to parse nominals hke: 
the tile J~m crearecl on Monclav 
the person tna~ the tile was created oy on Monday 
the day on vvn~ch Jtm create(:/ tl~e hie 
TO do tins. we ~ntroduce the conceDt of a relative case A 
relative case is a link back from the caseframes for the 
objects that fill the cases of a clausal caseframe to mat 
clausal caseframe. A grammar preprocessor generates a 
relatwe case automatically from each case of a clausal 
caseframe, associating ,t 'Nlth the nominal caseframe .~at 
fills the case in me clausal caseframe. Relative cases rio 
not need to be spemfied by the grammar writer For 
instance, a relative case ,s generaled from the createe case 
of "create" and rnctuded in the "hie" caseframe. It lOOkS 
like this: 
\[*file* 
(:relative-cf *create* 
:relative-case-name createe 
:marker <create> \] 
911 also clelerrrllnes I~le lense ol me sentence and whelne¢ ,l s 
,Jllfltrrtallve or neqallVe 
IOSn ,I u~ere ,s a case .~,ln a OoSlhO.al mq.ecboiolecI $1ol me 
,¢lGitec! .~DleCt is dlloweO lo iJasslv,ze Ne .:air thus uoderslano -;e~le,~<'es 
!IW~ " MaIV ,VaS ~iVell a boow " ,iOln I ",~ive ' .Ise!~,3me ,-,¢11 13oln a 
f\]if~,-' ,~lecl ,llt(~ ,\]ii ,it(~it'ecl )l}lel,~l ' ~'~ie 
156 
Note thai :marker is the same as :header of "create" 
Similar relative cases are generated in the "person" 
caseframe for the creator case. and in the "date" 
caseframe for the creation-date case. differing only in 
:relative-case-name 
Relative cases are used s~mdarly to the ordinary marked 
cases of nominal caseframes. In essence, ff the parser ~s 
parsmg a non,nat caseframe ~nd finds the marker of one 
of ~ts relative cases, then it tries to instanhate the :relative- 
cf It performs tms instantlatlon ~n the same way as ,f me 
relatwe.cf were a top-level clausal caseframe and the word 
that matched the header were ,is main verb. An ~mportan! 
d=fference ~s that it never tries to fill the case ,,,,nose name 
~s g=ven by relative-case-name That case =s hlled by the 
nommal caseframe which contams the relative case For 
mstance, suppose the parser =s tryCng to process. 
7"he file J~m createcl on MonclaV 
And suppose that ~t has already located "file ' and used 
that to determine ,t ,s ~nstanhat,ng a "file" nominal 
caseframe It ~s able to match {aga,nst 'created"~ me 
• marker of the relative caseframe of "hie' shown above. It 
then ~ries to ~nstanhate me relatwe.cf "create" using ~tS 
standard tecnmdues except real ~! does not try to fill 
createe the case of "create" specff=eo as the relallve-case- 
name Th~s mstanr~at~on succeeds wllh "Jim' gong =nip 
creator and "on Monday" bemg used to hll creatmn-date 
The parser then uses (a pomter to) the nommat caseframe 
currently being instant~ated. "file" to fill createe, the 
:relative-case-name case of "create" and the newly created 
instance of "create" is attached to this mstance of "file" as 
a modifier 
a 
b. 
~t never looks any further left ,n the ~nout than 
the header of the nom=r'al caseframe or ,f ,t 
~as already parsed any omer Oos'.-r~ommat 
cases of the nommal caseframe no further left 
than the r~ght hand end ot; them 
it COnsumes. but Otherwise ignores any relatwe 
pronouns iwno .,vn~;.m ~,.,n~n rr~ar ~ that 
~mmediately precede the segment used to 
instantiate the relatwe-cf Tnlg ~neans rna~ 3/i 
words, including "thar" .~vdl ~e 3ccounrec #or ~n 
"t/le file ttlat Jim createc .:.)t~ ~/lonclay" 
it does not try to fill the case specified by the 
relative-case-name ~n the relative-of: =nstead 
tms case is filled by (a Oomter to) the Or~g=nal 
nommal caseframe tnstance: 
d. ff the relal=ve-case.name specifies a marked 
case rather than a positional one tn the 
relative.of then ~ts case marker can De 
consumed, but omerwtse ~gnored. durmg 
mstanhataon of me relatwe.cf This 3110w3 US 
tO deal wlln "on ~n me .gate Jim created ~he 
hie on" or "the care un whlcn jim created the 
file ' 
3 Passwe relalave clauses (e g. "Ihe file that was 
created on Monday"t can generally be handled using 
the same mechanisms used Ior passwes at the main 
clause level However tn relative clauses, passives 
may sometimes be recIucec/ by om~thng the usual 
auxihary verb to be (and the relat=ve pronoun) as ~n: 
the file create(l on Monday 
To account for such reduced relative clauses, the 
verb cluster processor will produce approonate 
additional readings of the verio clusters ,n relahve 
clauses for which the relative pronoun JS m~ssmg 
This may lead to multlOle oarses, mcludmg one for 
the above example s~mdar to the correct one for: 
the file Jot~n crea\[e~ on Monclay 
These amb=guaties wdl De taken care of by Plume s 
standard ambiguity reduction methods 
More comotetely. Plumes atgor~mm for relattve clauses ~s: 
1. When processing a nommal caseframe. Plume scans 
for the ;markers of lhe rela{tve cases of the nominal 
caseframe at the same t~me as \[t scans for the 
regular case markers ol: that nominal caseframe 
2. If it finds a marker of a relatwe case. ~t rues to 
inst~ilntlate the relaltve.cf lust as though if were the 
Top-level clausal case|tame and the header were ~ts 
mmn '/erb. ~.xcept mat: 
2 \] interrogatives 
in addmon to handling passaves 3no -e¢ahve :lauses. 
also wish {he =nformatlon ~n me "c'eate -"aseframe 
hanclle ~nterrogatlves tnvolvlng "create' ~cn 3s 
,re 
to 
~1C Jim create me hl~. {~n MG;I,I\]V ' 
W,aS r/le /lie cre3teo OV J~m or} '.4L,",I.\]/~ 
,/I/ho c.reare(~ the hie On ~f,unc,av ' 
What clay was the hie crejleC ,: 
The prtmary diffiCulty for Plume .,.,~ln mterrogatwes ~s that 3S 
these examoles ShOw me number of variations in stanclard 
COnStituent order is much greater than for tmperatives and 
157 
dectaratJves. Interrogatives come in a w~de variety of forms. 
depending on whether the question is yes/no or wh: on 
which auxiliary verb ~s used: on whether the voice is active 
or passive: and for wh questions, on which case is queried. 
On the other hand. apart from var)ations in the order ancl 
placement of marked cases, there is only one standard 
constituent order for =mperatives and only two for 
declaratives (corresponding to active and passive voice). We 
have exl~lO=tecl th=s low variability by building knowledge of 
the imperative and declarative order into Plumes parsing 
algorithm. However this is impractical for the larger 
number of variations associalecl with interrogatives. 
Accordingly, we have designed a more data,driven approach 
This approach involves two Passes through the inpul: the 
first categorizes the input into one on several primary input 
categories incluOing yes-no questions, several kinds of wh- 
cluestions, statements, or ~mperat=ves. The second Pass 
performs a detaded parse of me input based on the 
ctassfficat=on made in the first Pass. The rules used contam 
bas=c syntactic ~nformat=on al3out Enghsn. and will rema,n 
constant for any of Plumes restricted domam grammars of 
semantic caseframes for Enghsh 
The first level of process=rig +nvolves an ordered set of 
r~D-/evel patterns. Each too.level pattern corresponds tO one 
of the primary =nput categor=es ment~onecl adore Th=s 
classificatory matchmg c~oes not attempt to match every 
+,vord +n the input sentence but only to do the ram=mum 
necessary to make the classdicat=on. Most of the relevant 
,nformat~on is found at the beg=nnmg of the ~nDuts. In 
ioart=cular, the top-level patterns make use of the fronted 
aux=liary verb and wh-worcls tn questions. 
AS well as classffymg the input, th~s top-level match ,s 
also useci to determme the iclenttty of the caseframe To be 
=nstant=ated. Th=s =S =moortant to dO at this stage because 
the deta,led recognmon Ln the seconcl phase ts neav=ly 
de~enclent on the ~clent=ty of his top-level casetrame The 
special symbol. SverO. that appears exactly once =n all top- 
level patterns, matches a heacler of any clausal caseframe 
We call trte caseframe whose heacler is matcnecl by SverO 
the primary casetrame for that input. 
The second more detailed parsing phase is organized 
relative to the primary caseframe Associated with each top- 
level pattern, there is a corresponding parse femo/ate. A 
parse template specifies which parts of the primary 
caseframe will' be found in unusual positions and which 
parls the default parsing process (the one for declarat=ves 
and imperatives) can be used for. 
A simplified example of a top-level pattern for a yes-no 
question is: ~ 
<aux> (- ($verD !! <aux>)~ (&s SverOj Srest 
This top.level pattern w=ll match inputs hke. me followmg: 
D~ Jim create fop ~ 
Was fop creafecl Oy J~m ? 
The first element of the above top-level pattern ~s an 
auxiliary verlo, represented Dy me non-termmal <aux> Th~s 
auxdiary ~s remembered and used by the veto cluster 
processor (as though ~t were the first auxd~ary ~n the cluster) 
to determine tense and voice. AcCOrChng tO the next part 
of the pattern, some word that ts not a verb or an aux~hary 
must appear after the fronted auxdiary and before the mare 
verb ( is the negation operator, and !! marks a 
dislunction). Next. the scanmng operator &,~ tetls the 
hatcher to scan until it finds $vero which matches the 
header of any clausal caseframe F~nally. Srest matches 
the remaimng ~nDut. 
If the top-level pattern successfully matches. Plume uses 
the assoc~atecl Parse template to clirect ~ts more detaded 
processmg of the ~npul. The goal of this second pass 
through the input ~s to mstantiate the caseframe 
corresponding to the heacler matched by Sverlo in the top- 
level pattern, The concept of a kernel-casetrame is 
important to this stage of processmg. A kemel-caseframe 
Corresponcls to that part of an ~nput that can be processect 
according to the algorithm already budt into Plume for 
declarative and imperative Sentences, 
P Ihl fhl~ ~allern. .'~nly ii1OuIS wrlefe tl~e tronfecl auxlllarv .¢+ ,'he first 
worO ,~ rh~ sentence are alloweo t'he rrl()re ",'+=nplex ~anerr; ~al ,s 
achJally .lsecI P)v PfLIIn~ dllc)ws ofeuu~lfiol)dll.~/ i~l,|fke 0 "ases ',~ ionear 
i~lihaliv as ,,felt 
158 
The parse template associated with the above top-level 
pattern for yes/no questions is: 
aux kernel-casetrame 
+ (:query) 
This template tells the parser that the input consists of the 
auxiliary verb matched in the first pass followed by a 
:kernel-caseframe. For example. ~n: 
O;d J~m create fop ~ 
the auxtliary verb. "did" appears hrst followed by a kernel- 
caseframe. "Jim create fop" Note ~ow the kernel- 
caseframe looks exactly like a declarative sentence, and so 
can be parsed according to the usual declarative/imperative 
parsing algorithm 
In addition to spec:ficatJon of where to find components of 
the primary caseframe a parse lemplate ~ncludes 
annotations (indicated by a plus sign) in the above 
template for yes/no questions, there =S lust one annotatton - 
~uery. Some annotations, hke thiS one ,ndlcate what type 
of input has been found, while others direct the processing 
of the parse template. Annotations o! the first type record 
which case is being queried ~n wn questfons, mat ~s. which 
case ,s associated w,m the wh word. Wh questions thus 
include one of the following annotatTons SuOlect-query. 
Prelect-query. and mar~ea-case-que~ Marked case queries 
correspond to examples like: 
On what day d~d J~m create too ° 
What day d~d Jim create /oo on ~ 
in which a case marked by a preposition iS 13eing asked 
aPout. AS illustrated here me case-marker in such queries 
can either precede the wn word or appear somewhere .after 
the verO. To deal w;m this, me parse template for marked 
case quenes has the annotation tloa~na-case-marker. This 
annotation ~s of the second type thai ,s =t affects the way 
Plume processes the associated parse template. 
Some top-level patterns result ~n two poss=bdmlles for parse 
templates, For example, the follow=no top-level pattern 
< ,'/n.'NorO > < at.ix > i ( Sv~rto ii .-- at.ix > ~ $vf~rt~ $',f=.~t 
could match an ObleCt query or a marked case query, 
~ncluding the following: 
What did Jsm create ~ 
By whom was fop created? sz 
Who was fop created Oy ? 
These ~nputs cannot be satisfactordy discriminated Oy a top- 
level pattern, so the above top-level pattern has twO different 
parse templates associated with it: 
wt~-ob/ect aux kemel-caseframe 
÷ (oOlecr.query~ 
wig-marked-case-tiller aux kernel-caseframe 
+ (roamed-case-query float~ng-case-mar~er} . 
When the above top-level pattern matches. Plume tries to 
parse the input using both of these parse templates, in 
general, only one wil! succeed Ln accounting for all me 
input, so the amb~gudy wdl De eliminated by the methods 
already built ~nto Plume. 
The method of parsing interrogatives presented above 
allows Plume to handle a wide variety of interrogatwes ~n a 
very general way using domain specific semantic caseframes. 
The writer of the caseframes does not have to worry about 
whether they will ioe used for ~mperative. declarative, or 
interrogative sentences. (or in relatwve clauses). He is free 
to concentrafe on the domain-specific grammar. In addition. 
the concept of the kernel-caseframe allows Plume to use 
the same efficient caseframe-based parsing algorithm that =t 
used for declarative and imperative sentences to parse 
malor subparts of questions. 
3. Conclusion 
Prey,puS work (e.g. \[4. 5. 81 / 3no exoer,ence .,vdh our 
current rmolementat~on of Plume. Carnegie 'Group s semantic 
caseframe parser, has ~nown semantic caseframe 
instanl=ation to be an efficient and mgnly roloust method of 
parsing restnctecl dommn tnout However hke other 
methods of parsing tleawly deoendent on restricted domain 
semantics these ,nmal attempts at parsers based on 
semantic caseframe =nslant;al~on suffer from palcny syntactic 
coverage. 
159 
After first describing the current ~mplementation of Plume, 
this paper presented a detaded design for endowing Plume 
with much broader syntact=c coverage including passives. 
interrogatives, and relat=ve clauses. Relative clauses are 
accommodated through some grammar preprocessing and a 
minor change in the processing of nominal caseframes 
Handling of interrogatives relies on a set of rules for 
classifying inputs into one of a limited number of types. 
Each of these types has one or more associated parse 
templates which guide the subsequent detailed parse of the 
sentence, As the final version of this paper is prepared 
(late April, 1985). the handling of passives and interrogatives 
has already been implemented in an internal development 
version of Plume. and relative clauses are expected to follow 
SOOn 
Though the above methods of incorporating syntactic 
generality into Plume do not Cover all of English syntax. 
trey show that a s=gnfficant degree of syntactic generality 
can Ioe provided straightforwardly t:)y a domain specific 
parser drtven from a semantic caseframe grarpmar 
References 
1. Bobrow. R J. The RUS System 8BN Report 3878. 
Bolt. Beranek. and Newman. 1978 
2. Brown. J. S and Burton, R R Multiple 
Representations of Knowledge for Tutorial Reasomng. In 
Representation and Understanding Bobrow. 0 G and 
Collins, A.. Ed., Academic Press. New York. 1975. pp. 
311-349. 
3. Burton, R. R. Semantic Grammar An Engineering 
Technique for Constructing Natural Language Understanding 
Systems. BBN Report 3453. Bolt. 8eranek, and Newman. 
Inc.. Cambridge. Mass.. Oecember. 1976. 
4. Carbonell. J. G.. Boggs. W. M. Mauldin, M. L.. and 
Anick, P. G. The XCALIBUR Prolect: A Natural Language 
Interface to Expert Systems. Proc. Eighth Int. Jr. Conf on 
Artificial Intelligence. Karlsruhe. August. 1983. 
5. Carbonetl. J. G. and Hayes P J. "Recovery Strategies 
for Parsing Extragrammatical Language" Comoutat~ona/ 
Lingulstscs 10 (1984). 
6. Grosz, B. J. TEAM: A Transportable Natural Language 
Interface System Proc. Conf on Applied Natural Language 
Processing, Santa Mon,ca. February 1983 
7. Haas. N and Hendnx. G G. An Approach to AccluJrmg 
and Applying Knowledge Proc. Nattonat Conference of the 
American Assoc=ation for Artific=al Intelligence. Stanford 
University. August. 1980. pp. 235-239 
8. Hayes, P J. and Carbonetl. J G. Multt-Strategy 
Parsing and its Role ~n Robust Man-Machine Commun=cat=on. 
Carneg=e-Metlon Umvers=ty Computer Sc=ence Oepartment, 
May, 1981. 
9. Hendnx. G. G. Human Engineering for Applied Natural 
Language Process=ng. Proc Fift~ Int. Jr. Conf on Art=fvctai 
Intelligence, MIT. 1977. pp. 183-191 
10. Woods. W. A, "Cascaded ATN Grammars' Arnertc3r~ 
Journal of Computational Linguistics 6. 1 (August 1980Y 1-t2 
160 
