Lab 7 (Due 2/20 11:00pm)

Preliminaries

These instructions might get edited a bit over the next couple of days. I'll try to flag changes.

As usual, check the write up instructions first. Especially in the test corpus section, but also in general, it will be helpful to keep notes along the way as you are doing grammar development.

Requirements for this assignment

• 0. Make sure you have a baseline test suite corresponding to your lab 6 grammar.
• 1. Check that negation is working, and fix it if necessary.
• 2. Find a simple sentence from your test corpus and try to get your grammar to be able to parse it.
• 3. Get wh questions working.
• 3. Make sure your grammar can still generate, and debug as necessary.
• 4. Test your grammar using [incr tsdb()]. [incr tsdb()] should be part of your test-development cycle. In addition, you'll need to run a final test suite instance for this lab to submit along with your basline.
• 5. Write up the phenomena you have analyzed.

Run a baseline test suite

Before making any changes to your grammar for this lab, run a baseline test suite instance. If you decide to add items to your test suite for the material covered here, consider doing so before modifying your grammar so that your baseline can include those examples. (Alternatively, if you add examples in the course of working on your grammar and want to make the snapshot later, you can do so using the grammar you turned in for Lab 6.)

The negation library is more robust than in previous years, so we expect that in most cases the output is working or close to working.

• Parse a simple negated sentence and see if gets the right semantics. Here is a sample from English for The dog doesn't sleep.
• If the sentence doesn't parse, post to GoPost with an explanation of how negation works in your language.
• If the sentence parses, but the semantics is wrong, post to GoPost with the semantics you are getting and info on how negation works in your language.

One sentence from the test corpus

The goal of this section is to parse one more sentence from your test corpus than you are before starting this section. In most cases, that will mean parsing one sentence total. In your write up, you should document what you had to add to get the sentence working. Note that it is possible to get full credit here even if the sentence ultimately doesn't parse by documenting what you still have to get working.

This is a very open-ended part of the lab (even more so than usual), which means: A) you should get started early and post to GoPost so I can assist in developing analyses of whatever additional phenomena you run accross and B) you'll have to restrain yourselves; the goal isn't to parse the whole test corpus this week ;-).

• Create a profile from your test corpus skeleton, and run a baseline.
• Use Browse | Results to see if anything is parsing.
• Look for some plausible candidate sentences. These should be relatively short and ideally have minimal additional grammatical phenomena beyond what we have already covered.
• Examine the lexical items required for your target sentence(s). Add any that should belong to lexical types you have already created.
• Try parsing the test corpus again (or just your target sentence from it).
• If your target sentence parses, check the MRS to see if it is reasonable.
• If your target sentence doesn't parse, check to see whether you still have lexical coverage errors. Fixing these may require adapting existing lexical rules, adding lexical rules, and/or adding lexical types. Post to GoPost for assistance.
• If your target sentence doesn't parse but your grammar does find analyses for each lexical item, then examine the parse chart to identify the smallest expected constituent that the grammar is not finding, and debug from there. Do you have the phrase structure rule that should be creating the constituent? If so, try interactive unification to see why the expected daughters aren't forming a phrase with that rule. Do you need to add a phrase structure rule? Again, post to GoPost for assistance.
• Iterate until either the sentence parses or you at least have a clear understanding of what you would need to add to get it parsing.
• Run your full test suite after any changes you make to your grammar to make sure you aren't breaking previous coverage/introducing spurious ambiguity.

Wh-questions

In constructing your testsuite for this phenomenon in a previous lab, you were asked to find the following:

• The simplest case, where there is a single clause and one argument is questioned: Who did the child see?/Who saw the child?
• The shape of the wh words for core arguments. Do these vary with case, animacy, gender, something else?
• The possible positions of wh words: Do they appear where an ordinary argument would? Move to the beginning of the clause? Are both of these possible?
• What happens if the questioned argument belongs to a lower clause (e.g. Who did the observer think the child saw?)?
• Are there any other differences between wh questions and declaratives (or yes-no questions)? (For example, English requires subject-auxiliary inversion in the main clause of a matrix wh-question.)
• Are there are any differences between wh questions concerning subject and non-subject arguments? (For example, English does not do subject-auxiliary inversion if the questioned element is the main clause subject.)
• Optional: What happens with multiple wh elements in the same clause (e.g. Who saw what?)

In the following, I'll share the tdl I've developed in a small English grammar, for two possibilities:

1. Actual English (wh words go to the start of the clause, with their position indicating whether the matrix or subordinate clause is the question)
2. Pseudo-English, where wh words stay put

Your goal for this part of the lab is to use this as a jumping-off point to handle wh questions as they manifest in your language. Of course, I expect languages to differ in the details, so please start early and post to GoPost so we can work it out together.

Wh pronouns

Type and entry definitions for my tdl pronouns (used in both versions):

wh-pronoun-noun-lex := norm-hook-lex-item & basic-icons-lex-item & 
  [ SYNSEM [ LOCAL [ CAT [ HEAD noun,
			   VAL [ SPR < >,
				 SUBJ < >,
				 COMPS < >,
				 SPEC < > ] ],
		     CONT [ RELS < ! [ LBL #larg,
				       ARG0 #ind & ref-ind ],
				  [ PRED "wh_q_rel",
				    ARG0 #ind,
				    RSTR #harg ] ! >,
			    HCONS < ! [ HARG #harg,
				        LARG #larg ] ! > ] ],
	     NON-LOCAL.QUE < ! #ind ! > ] ].
				    
what := wh-pronoun-noun-lex &
  [ STEM < "what" >,
    SYNSEM.LKEYS.KEYREL.PRED "_thing_n_rel" ].

who := wh-pronoun-noun-lex &
  [ STEM < "who" >,
    SYNSEM.LKEYS.KEYREL.PRED "_person_n_rel" ].

Ancillary changes (both versions)

• Constrained the value of NON-LOCAL on the root symbol in roots.tdl to non-local-none.
• Changed basic-zero-arg to norm-zero-arg everywhere.
• Added norm-zero-arg as supertype for adverb-lex.
• Modified bare-np-phrase to inherit from head-valence-phrase as an additional supertype (this copies up the NON-LOCAL value).
• Modified bare-np-phrase to constrain the element of the daughter's non-empty SPR list to be unexpressed
• Modified subj-raise-aux to constrain the element of the non-empty SUBJ list of its complement to be unexpressed
• Made the following modifications to the analysis of coordination (as type addenda):

  topormid-coord-phrase :+ [ SYNSEM.NON-LOCAL #nl,
     LCOORD-DTR.SYNSEM.NON-LOCAL #nl,
     RCOORD-DTR.SYNSEM.NON-LOCAL #nl ].
  			  
  bottom-coord-phrase :+ [ SYNSEM.NON-LOCAL #nl,
     NONCONJ-DTR.SYNSEM.NON-LOCAL #nl ].			  
  

Wh-initial phrase structure rules

Note that all the phrase structure rules require instances in rules.tdl

basic-head-filler-phrase :+
   [ ARGS < [ SYNSEM.LOCAL.COORD - ], [ SYNSEM.LOCAL.COORD - ] > ].

wh-ques-phrase := basic-head-filler-phrase & interrogative-clause & 
		  head-final &
   [ SYNSEM.LOCAL.CAT [ MC bool,
			VAL #val,
			HEAD verb & [ FORM finite ] ],
     HEAD-DTR.SYNSEM.LOCAL.CAT [ MC na,
				 VAL #val & [ SUBJ < >,
					      COMPS < > ] ],
     NON-HEAD-DTR.SYNSEM.NON-LOCAL.QUE < ! ref-ind ! > ].
			

extracted-comp-phrase := basic-extracted-comp-phrase &
  [ SYNSEM.LOCAL.CAT.HEAD verb ].

extracted-subj-phrase := basic-extracted-subj-phrase &
  [ SYNSEM.LOCAL.CAT.HEAD verb ].

Wh in situ phrase structure rule

Note that all the phrase structure rules require instances in rules.tdl

wh-int-cl := clause & head-compositional &  head-only &
  [ SYNSEM [ LOCAL.CAT [ VAL #val,
			 MC bool ],
	     NON-LOCAL non-local-none ],
    C-CONT [ RELS < ! ! >,
	     HCONS < ! ! >,
	     HOOK.INDEX.SF ques ],
    HEAD-DTR.SYNSEM [ LOCAL.CAT [ HEAD verb & [ FORM finite ],
				  VAL #val & 
				    [ SUBJ < >,
				      COMPS < > ] ],
		      NON-LOCAL [ SLASH < ! ! >,
				  REL < ! ! >,
				  QUE < ! ref-ind ! > ] ] ].

The general head-subj type assumes that QUE is empty, which won't fly in this case, so we need to redefine it. In the pseudo-English grammar, I did it this way:

eng-subj-head-phrase := head-valence-phrase & head-compositional & 
              basic-binary-headed-phrase &
  [ SYNSEM phr-synsem & 
           [ LOCAL.CAT [ POSTHEAD +,
                 HC-LIGHT -,
                 VAL [ SUBJ < >,
                       COMPS #comps,
                       SPR #spr ] ] ],
    C-CONT [ HOOK.INDEX.SF prop-or-ques,
         RELS < ! ! >,
         HCONS < ! ! >,
         ICONS < ! ! > ],
    HEAD-DTR.SYNSEM.LOCAL.CAT.VAL [ SUBJ < #synsem >,
                    COMPS #comps,    
                    SPR #spr ],
    NON-HEAD-DTR.SYNSEM #synsem & canonical-synsem &
       [ LOCAL [ CAT [ VAL [ SUBJ olist,
                 COMPS olist,
                 SPR olist ] ] ],
         NON-LOCAL [ SLASH 0-dlist & [ LIST < > ],
             REL 0-dlist ] ]].

... and then had subj-head in rules.tdl instantiate this type instead of subj-head-phrase.

If your language has head-opt-subj, this will need to be rewritten similarly.

For each of the following phenomena, please include the following your write up:

1. A descriptive statement of the facts of your language.
2. Illustrative IGT examples from your testsuite. These should be examples that actually work in the current grammar, or would work if not for the particular problem you are talking about.
3. A statement of how you implemented the phenomenon (in terms of types you added/modified and particular tdl constraints).
4. If the analysis is not (fully) working, a description of the problems you are encountering.
5. A statement of whether or not you can generate from examples illustrating the phenomenon.

Phenomena:

• Negation
• Whatever you fixed about your grammar as you worked on the test corpus sentence. (In this section, please include the test corpus example you are targeting and a narrative of what you worked on to try to get it parsing.)
• Wh-questions

In addition, your write up should include a statement of the current coverage of your grammar over your test suite (using numbers you can get from Analyze | Coverage and Analyze | Overgeneration in [incr tsdb()]) and a comparison between your baseline test suite run and your final one for this lab (see Compare | Competence).

Submit your assignment

• If you're using svn for version control, run svn export to make a copy of your lab directory that does not include .svn files.
• Remove extraneous [incr tsdb()] profiles from the copied directory. (I'd like the initial baseline and final result for both test suite and test corpus; Only keep intermediate versions that you specifically want to say something about.)
• Create a tarball of your grammar, your tsdb directory including both initial and final profiles, and your write up. The best way to do this (so that it unpacks most easily when I download from CollectIt) is to cd into the directory containing your lab (e.g., cd lab7/) and do:

  tar czf lab7.tgz *

  (When I download your submission from CollectIt, it comes in a directory named with your UWNetID. The above method avoids extra directory structure inside that directory.)

• Upload the tarball to CollectIt