Multiple processing stages in dialogue top-level

When building dialogue applications, it's quite often the case that there are multiple stages in the process of converting the LF (the thing that comes out of the recognizer) into a dialogue move. I've just added some hooks so that you can pass back the intermediate levels of representation as an optional extra argument to lf_to_dialogue_move, and display them. This is useful for debugging.

Here's a text example from SHRD2:

>> is the large red block in the box

      Old state: []
             LF: [[ynq, 
                   form(present, 
                        [[be, term(the_sing,block,[[size,large],[color,red]]), 
                          [in_loc,term(the_sing,box,[])]]])]]
 Intermediate 1: [[ynq, 
                   scoping_unit(term(event_exists, A, 
                                     [[be, A, 
                                       term(the_sing, B, 
                                            [[block,B],[size,B,large],[color,B,red]]),
                                       [in_loc,term(the_sing,C,[[box,C]])]],
                                      [tense,A,present]]))]]
 Intermediate 2: [[ynq, 
                   quant(the_sing, A, [[block,A],[size,A,large],[color,A,red]], 
                         quant(the_sing, B, [[box,B]], 
                               quant(event_exists, C, 
                                     [[be,C,A,[in_loc,B]],[tense,C,present]], true)))]]
  Dialogue move: [[ynq, 
                   quant(the_sing, A, [[block,A],[size,A,big],[color,A,red]], 
                         quant(the_sing, B, [[box,B]], 
                               quant(event_exists,C,[[be_in_loc,C,A,B],[tense,C,present]],true)))]]
Abstract action: say(i_dont_understand,present)
Concrete action: tts(sorry, I don't understand)
      New state: []

Intermediate 1 is after addition of variables; Intermediate 2 is after scoping; and Dialogue move is after rewriting of lexical predicates. This last step is still very primitive.

CAT and FEAT commands

One of the good things about doing some grammar development on SHRD2 is that it suggests ideas for new development environment functionality. I got tired of consulting the grammar every time I needed to find out what features a category had, or what possible values a feature could take. So I added a couple of new commands called CAT and FEAT, which give you those pieces of information. Here's an example:

>> CAT p
(Display information for specified category)

Features for category "p": [def,obj_sem_n_type,postposition,sem,sem_p_type,sem_pp_type]

--- Performed command CAT p, time = 0.00 seconds

>> FEAT sem_p_type         
(Display information for specified feature)

Feature values for feature "sem_p_type": [[back,down,none,normal,off,onoff,over,up,updown]]

--- Performed command FEAT sem_p_type, time = 0.00 seconds

Showing missing vocabulary in EBL_TREEBANK

A trivial but rather useful little feature I just added: when you run EBL_TREEBANK, you now get missing vocabulary displayed for relevant sentences. I don't know why I didn't do this years ago. Here's an example. To get the new functionality, you just need to update Regulus from CVS, nothing needs to be remade.

>> EBL_TREEBANK
(Parse all sentences in current EBL training set into treebank form)

--- Read parsing history file (114 records) d:/cygwin/home/speech/regulus/examples/shrd2/generated/shrd2_parsing_history.pl
--- Incremental treebanking switched off, not trying to convert treebank

Parsing corpus data in d:/cygwin/home/speech/regulus/examples/shrd2/corpora/shrdlu_corpus.pl:
..
*** Parsing failed for: "find a block which is taller than the one you are holding and put it into the box", line 2
...
*** Parsing failed for: "is at least one of them narrower than the one which i told you to pick up", line 6
Words not in current vocabulary: [told]
.....
*** Parsing failed for: "will you please stack up both of the red blocks and either a green cube or a pyramid", line 12
Words not in current vocabulary: [either]
...

Parsing top-level constituents and treebank caching

Since parsing with non-top constituents had a bad effect on efficiency, the LOAD command has gone back to loading the normal grammar, as it did before. If you want to be able to parse with non-top constituents, I have introduced a new command, LOAD_DEBUG, which loads an extended version of the grammar suitable for debugging. You are advised not to use this for creating specialised grammars.

The initial version of this functionality turned out to have a rather nasty bug, which is I think the thing that got Beth Ann yesterday... there was an incorrect interaction between LOAD_DEBUG, grammar caching and treebank caching. This meant that treebank creation sometimes incorrectly thought that the grammar rules had been changed when in fact they hadn't, and unnecessarily reparsed the training corpus. Beth Ann, please update from Regulus and see if this is now fixed!

Parsing non-top constituents (continued)

I have now checked in an improved version of the functionality for parsing non-top constituents, which hides the dummy rules and shows the features for the constituent. Here are a couple of examples from Toy1Specialised:

>> np the light in the kitchen
(Parsing with left-corner parser)

Analysis time: 0.55 seconds

Return value: [[device,light],[location,kitchen],[prep,in_loc],[spec,the_sing]]

Global value: []

Syn features: [agr=3/\sing,case=A,conj=n,def=y,gapsin=B,gapsout=B,n_appositive_mod_type=none,
n_of_mod_type=none,nform=normal,pronoun=n,sem_n_type=dimmable\/switchable,
syn_type=np_with_noun,takes_about_pp=n,takes_attrib_pp=n,takes_cost_pp=n,
takes_date_pp=n,takes_duration_pp=n,takes_frequency_pp=n,takes_from_pp=n,
takes_loc_pp=n,takes_partitive=n,takes_passive_by_pp=none,takes_post_mods=n,
takes_side_pp=n,takes_time_pp=n,takes_to_pp=n,takes_with_pp=n,wh=n]

Parse tree:

np [GENERAL_ENG:2026-2044]
/  np [GENERAL_ENG:1864-1874]
|  /  d lex(the) [GEN_ENG_LEX:341-344]
|  |  nbar [GENERAL_ENG:2071-2083]
|  \     n lex(light) [TOY1_LEX:44-47]
|  post_mods [GENERAL_ENG:1591-1680]
|  /  pp [GENERAL_ENG:1747-1765]
|  |  /  p lex(in) [TOY1_LEX:51-58]
|  |  |  np [GENERAL_ENG:2026-2044]
|  |  |  /  np [GENERAL_ENG:1864-1874]
|  |  |  |  /  d lex(the) [GEN_ENG_LEX:341-344]
|  |  |  |  |  nbar [GENERAL_ENG:2071-2083]
|  |  |  |  \     n lex(kitchen) [TOY1_LEX:38-39]
|  |  \  \  post_mods null [GENERAL_ENG:1410-1416]
\  \  post_mods null [GENERAL_ENG:1410-1416]

------------------------------- FILES -------------------------------
GENERAL_ENG: c:/cygwin/home/speech/regulus/grammar/general_eng.regulus
GEN_ENG_LEX: c:/cygwin/home/speech/regulus/grammar/gen_eng_lex.regulus
TOY1_LEX:    c:/cygwin/home/speech/regulus/examples/toy1specialised/regulus/toy1_lex.regulus

>> n light
(Parsing with left-corner parser)

Analysis time: 0.02 seconds

Return value: [[device,light]]

Global value: []

Syn features: [agr=3/\sing,conj=n,n_appositive_mod_type=none,n_of_mod_type=none,
n_post_mod_type=none,n_pre_mod_type=loc,sem_n_type=dimmable\/switchable,
takes_about_pp=n,takes_attrib_pp=n,takes_cost_pp=n,takes_date_pp=n,takes_det_type=def,
takes_duration_pp=n,takes_frequency_pp=n,takes_from_pp=n,takes_loc_pp=y,
takes_partitive=n,takes_passive_by_pp=none,takes_side_pp=n,takes_time_pp=n,
takes_to_pp=n,takes_with_pp=n]

Parse tree:

n lex(light) [TOY1_LEX:44-47]

------------------------------- FILES -------------------------------

TOY1_LEX: c:/cygwin/home/speech/regulus/examples/toy1specialised/regulus/toy1_lex.regulus

Parsing non-top constituents

Following a conversation with Pierrette last week, I realised that there was an easy way to fix things so that we can parse non-top constituents in the LC (normal) parser, as well as the DCG one. I have just checked in a first version of the new functionality. Now, when you load a grammar using the LOAD command, an extra file of dummy rules is created and added to the ones explicitly specified. There is one dummy rule for each category Cat in the grammar, of the form

dummy_top:[sem=Sem] --> Cat, Cat:[sem=Sem]

For example, the dummy rule for 'np' is

dummy_top:[sem=Sem] --> np, np:[sem=Sem]

What this means is that you can now parse NPs at top-level by simply prefacing them with the word 'np'. Thus for instance in Calendar we can do things like the following:

>> np the last meeting in geneva
(Parsing with left-corner parser)

Analysis time: 0.97 seconds

Return value: [[at_loc,[[spec,name],[head,geneva]]],[head,meeting],[spec,the_last]]

Global value: []

Syn features: []

Parse tree:

.MAIN [CALENDAR_DUMMY_TOP_LEVEL_RULES:1-1]
   dummy_top [CALENDAR_DUMMY_TOP_LEVEL_RULES:22-22]
   /  lex(np)
   |  np [GENERAL_ENG:2026-2044]
   |  /  np [GENERAL_ENG:1849-1863]
   |  |  /  d lex(the) lex(last) [GEN_ENG_LEX:355-355]
   |  |  |  nbar [GENERAL_ENG:2071-2083]
   |  |  \     n lex(meeting) [CALENDAR_LEX:88-89]
   |  |  post_mods [GENERAL_ENG:1591-1680]
   |  |  /  pp [GENERAL_ENG:1747-1765]
   |  |  |  /  p lex(in) [CALENDAR_LEX:151-151]
   |  |  |  |  np [GENERAL_ENG:1955-1963]
   |  |  |  \     name lex(geneva) [GENERATED_NAMES:41-41]
   \  \  \  post_mods null [GENERAL_ENG:1410-1416]

------------------------------- FILES -------------------------------

CALENDAR_DUMMY_TOP_LEVEL_RULES: c:/cygwin/home/speech/regulus/examples/calendar/generated/calendar_dummy_top_level_rules.regulus
CALENDAR_LEX:                   c:/cygwin/home/speech/regulus/examples/calendar/regulus/calendar_lex.regulus
GENERAL_ENG:                    c:/cygwin/home/speech/regulus/grammar/general_eng.regulus
GENERATED_NAMES:                c:/cygwin/home/speech/regulus/examples/calendar.regulus
GEN_ENG_LEX:                    c:/cygwin/home/speech/regulus/grammar/gen_eng_lex.regulus

Semantic triples: []

No preferences apply

I should be able to improve this a little, in particular by adding some functionality to display the features on the non-top constituent as well as the semantics, but hopefully the existing version will already be quite useful.

Running multiple copies of the GUI

Elisabeth did a little work over the weekend, and it's now possible to run multiple copies of the GUI simultaneously - this is an important feature that people have been requesting for some time. The solution turns out to be embarrassingly simple. All we needed to do, in the end, was fix things so that it's possible for both the Java and the Prolog processes to specify from the command line which port they use to communicate with each other. As long as different {Java, Prolog} pairs use different ports, they don't interfere with each other.

I've added an example script to Regulus/Java called run_prolog_and_java2.bat - this is just like run_prolog_and_java.bat, but starts a second pair of processes, communicating over a new port.

Printing N-best feature info at top level

If you're in dialogue mode, and have N-best preferences defined, you now get them printed out at top level. This is useful for debugging feature definitions. Here's an example from the Calendar application:

>> what was the last meeting

      Old state: [lf=[[whq,form(past,[[be,term(the_last,meeting,[]),[loc,where]]])]], 
                  referents=[record(meeting,meeting_10),attribute(meeting,meeting_10,where)]]
             LF: [[whq,form(past,[[be,term(the_last,meeting,[]),term(what,null,[])]])]]
    Resolved LF: [[whq,form(past,[[be,term(the_last,meeting,[]),term(what,null,[])]])]]
     Resolution: [trivial]
  Dialogue move: [tense_information=referent(past), utterance_type=whq, 
                  aggregate(last_n_meetings(1),[])]
  Resolved move: [tense_information=interval(datime(1980,0,0,0,0,0),datime(2008,5,28,18,27,24)),
                  utterance_type=whq, aggregate(last_n_meetings(1),[])]
     Paraphrase: list meetings in past the last meeting
Abstract action: say(referent_list([record(meeting,meeting_10)]))
Concrete action: tts(meeting at pierrette 's room on november 25)
      New state: [lf=[[whq,form(past,[[be,term(the_last,meeting,[]),term(what,null,[])]])]], 
                  referents=[attribute(meeting,meeting_10,where),record(meeting,meeting_10)]]

N-BEST FEATURES AND SCORES:

rank                                    -1.00 * 0.00 = 0.00
no_dialogue_move                        -50.00 * 0.00 = 0.00
underconstrained_query                  -10.00 * 0.00 = 0.00
inconsistent_tense                      -10.00 * 0.00 = 0.00
non_indefinite_existential              -10.00 * 0.00 = 0.00
non_show_imperative                     -50.00 * 0.00 = 0.00
definite_meeting_and_meeting_referent   3.00 * 0.00 = 0.00

Total score: 0.00

Dialogue processing time: 0.00 seconds

>> when did that meeting start

      Old state: [lf=[[whq,form(past,[[be,term(the_last,meeting,[]),term(what,null,[])]])]], 
                  referents=[attribute(meeting,meeting_10,where),record(meeting,meeting_10)]]
             LF: [[whq,form(past,[[start,term(that,meeting,[])],[time,when]])]]
    Resolved LF: [[whq,form(past,[[start,term(that,meeting,[])],[time,when]])]]
     Resolution: [trivial]
  Dialogue move: [query_object=start_time, referent_from_context=meeting, 
                  tense_information=referent(past), utterance_type=whq]
  Resolved move: [meeting=meeting_10, query_object=start_time, referent_from_context=meeting, 
                  tense_information=interval(datime(1980,0,0,0,0,0),datime(2008,5,28,18,27,35)),
                  utterance_type=whq]
     Paraphrase: start time for that meeting in past
Abstract action: say(referent_list([attribute(meeting,meeting_10,start_time)]))
Concrete action: tts(10 00 on november 25)
      New state: [lf=[[whq,form(past,[[start,term(that,meeting,[])],[time,when]])]], 
                  (referents
                   = 
                   [attribute(meeting,meeting_10,where), record(meeting,meeting_10), 
                    attribute(meeting,meeting_10,start_time)])]

N-BEST FEATURES AND SCORES:

rank                                    -1.00 * 0.00 = 0.00
no_dialogue_move                        -50.00 * 0.00 = 0.00
underconstrained_query                  -10.00 * 0.00 = 0.00
inconsistent_tense                      -10.00 * 0.00 = 0.00
non_indefinite_existential              -10.00 * 0.00 = 0.00
non_show_imperative                     -50.00 * 0.00 = 0.00
definite_meeting_and_meeting_referent   3.00 * 1.00 = 3.00

Total score: 3.00

Dialogue processing time: 0.01 seconds