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.
There are several places in this lab
where I ask you to contact me if your grammar requires information
not in these instructions. Please read through this lab by class on
Wednesday, preferably earlier, so we can start that conversation in a timely fashion.
Requirements for this assignment
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 5.)
The semantics for declarative and interrogative clauses will be the same except for the value of the feature SF (sentential force) on the event index of the main predicate.
The customization script may have provided the right kind of semantics for matrix yes-no questions already. Try parsing an example from your test suite. If it parses, examine the MRS. Is the value of SF on the INDEX of the clause ques? (Or in the case of intonation questions only, do you get prop-or-ques?)
If your yes-no question doesn't parse, or if it does but not with the right semantics, contact me, and we will work out what needs to be done.
We will be using clausal complements as our example of embedded clauses. To do so, we need to create clause-embedding verbs. First, find examples of verbs that can embed propositions and verbs that can embed questions. If you also find verbs that are happy to embed either, we can make use of them. For inspiration, you can look here or here.
If your matrix and embedded clauses look the same, you should be able to test this immediately. If not, you'll have to wait until you've implemented the syntax for your embedded clauses.
Some languages mark embedded clauses (declaractive, interrogative or both) with complementizers (e.g., that and whether in English). To implement this, you'll need to do the following. (If your language also marks matrix questions with a question particle, you have some of the following in your grammar already.)
Test your embedded clauses. Do they parse as expected? Can you still generate?
Other possible syntactic differences between main and subordinate clauses include:
Consult with me to work out an analysis for whatever your language is doing in this case.
If your matrix and embedded clauses have different syntactic properties (e.g., presence v.\ absence of complementizers), you'll need to constrain things so that the embedded clause syntax only appears in embedded clauses and vice versa for matrix clause syntax. There are three resources for doing so:
If the difference is strictly S v. CP, you don't need the feature MC. Otherwise, you probably will need all three: The root condition will require [MC +], the embedding verb will require [MC -], and the constructions/lexical rules/etc which create the embedded and matrix clauses themselves should set appropriate values for MC.
Be sure your test suite contains negative examples illustrating
matrix clause syntax in embedded clauses and vice versa.
Check your MRSs
Here are some examples to give you an idea of what we're looking for.
I know that you sleep.
Note the qeq linking the ARG2 position of _know_v_rel (h18) to the LBL of _sleep_v_rel (h14), and the SF value of e15 (PROP).
<h1, e2:PRESENT:PROP-OR-QUES,
{ h3:_pronoun_n_rel(x4:IN-FOC:FIRST:SG),
h5:exist_q_rel(x4, h6, h7),
h1:_know_v_rel(e2, x4, h8),
h9:_pronoun_n_rel(x10:IN-FOC:SECOND),
h11:exist_q_rel(x10, h12, h13),
h14:_sleep_v_rel(e15:PRESENT:PROP, x10) }
{h6 qeq h3
h8 qeq h14
h12 qeq h9} >
I ask whether you sleep.
Note the qeq linking the ARG2 position of _ask_v_rel (h18) to the LBL of _sleep_v_rel (h14), and the SF value of e15 (QUES).
<h1, e2:PRESENT:PROP-OR-QUES,
{ h3:_pronoun_n_rel(x4:IN-FOC:FIRST:SG),
h5:exist_q_rel(x4, h6, h7),
h1:_ask_v_rel(e2, x4, h8),
h9:_pronoun_n_rel(x10:IN-FOC:SECOND),
h11:exist_q_rel(x10, h12, h13),
h14:_sleep_v_rel(e15:PRESENT:QUES, x10) }
{h6 qeq h3
h8 qeq h14
h12 qeq h9} >
The goal of this lab is to extend the grammars to cover sentences where the main (semantic) predicate is not a verb, i.e., NP, PP, and AP predicates. In some languages (including English) such predicates require the "support" of a particular bleached verb (the copula, or perhaps a verb of location). In others, they can serve as predicates on their own. In still other languages, we find a mix: The copula (or other verb) is required for certain types of predicates or in certain tenses but not others. Or the copula (or other verb) is optional: possible but not required.
It's also possible that in some languages the copula is optional in matrix clauses but required in embedded clauses. I haven't found an example like this yet, but I'd be curious to know about it if you find one.
Some of your grammars have adpositions already, but few, if any, have semantically contentful adpositions. You'll need to define these for this lab. The matrix provides a type basic-int-mod-adposition-lex, which should have most of the information required. Define a subtype with appropriate constraints on the MOD and VAL values, and try it out to see what else you might need to add.
We analyze copulas as semantically empty auxiliaries. You may already have a type very similar to this. The copula is likely to have different requirements on its complement than other auxiliary verbs, so you'll probably need to create subtypes, or for each. The tdl for a copula should look something like this:
copula-verb-lex := verb-lex & trans-first-arg-raising-lex-item-2 &
[ SYNSEM.LOCAL [ CAT.VAL [ SUBJ < #subj >,
COMPS < #comps >,
SPR < >,
SPEC < > ],
CONT.HOOK.XARG #xarg ],
ARG-ST < #subj &
[ LOCAL [ CONT.HOOK.INDEX #xarg,
CAT [ VAL [ SPR < >,
COMPS < > ],
HEAD noun ] ] ],
#comps &
[ LOCAL.CAT [ VAL [ COMPS < > ],
HEAD +jp ] ] > ].
The constraint [HEAD +jp] on the complement specifies that the complement should be (headed by) an adjective or an adposition. Depending on where copulas are required in your language, you might want to change this. If you need to give adjectives or adpositions non-empty SUBJ lists (e.g., because they can be stand-alone predicates in some cases; see below), then you'll also want to constrain the COMPS's SUBJ to be < [ ] > (aka cons) to make sure that the subject isn't realized twice.
Note that the copula verb uses the XARG to do the linking (the relevant constraint is declared on the supertype trans-first-arg-raising-lex-item in matrix.tdl). This means that the adjectives and adpositions will need to link their ARG1 to their XARG. This may already be the case, but you should double check.
We will follow the ERG in positing a different copula for use with NP predicates. This is because we don't want to give every noun a semantic argument position for a potential subject. The copula verb for NP predicates will instead introduce an elementary predication linking its subject and complement.
This means that in many languages, this copula might just be an ordinary transitive verb. It's not in English, because it also has auxiliary properties. If the NP-predicate-supporting-copula in your language differs in its behavior from (other) transitive verbs, post to GoPost.
The PRED value for this verb should be "_be_v_id_rel".
locative-verb-lex := verb-lex & trans-first-arg-raising-lex-item-1 &
[ SYNSEM.LOCAL [ CAT.VAL [ SUBJ < #subj >,
COMPS < #comps >,
SPR < >,
SPEC < > ],
CONT.HOOK.XARG #xarg ],
ARG-ST < #subj &
[ LOCAL [ CONT.HOOK.INDEX #xarg,
CAT [ VAL [ SPR < >,
COMPS < > ],
HEAD noun ] ] ],
#comps &
[ LOCAL.CAT [ VAL [ COMPS < > ],
HEAD adp ] ] > ].
Note that there are many share constraints between this and copula-verb-lex. If you have both, please make a supertype for the shared constraints.
The lexical entry for the locative verb can introduce "_be+located_v_rel" as its LKEYS.KEYREL.PRED.
If your language allows APs and PPs as stand-alone predicates, the basic strategy is to modify the selecting contexts for sentences (initial symbol, clause embedding verbs) to generalize the requirements on HEAD. This needs to be done slightly differently depending on how tense/aspect are marked in these clauses.
Note that some languages don't have adjectives at all, just a class of stative intransitive verbs. For present purposes, the definitive test is what happens when these elements modify nouns. If they appear to enter the same construction as relative clauses headed by transitive verbs (and non-stative intransitives), then they're just verbs. However, for the purposes of the MT exercise, it will be helpful to have their PRED values end in _a_rel, rather than _v_rel.
The first step is to get from the attributive entries for As or Ps (or both) to predicative uses. The attributive entries should have empty SUBJ values and non-empty MOD values. The predicative entries should have empty MOD values and non-empty SUBJ values. In addition, the attributive As and Ps share their INDEX with the INDEX of the element they modify, but predicative As and Ps need to have their INDEX point to their own ARG0, and have their SUBJ's INDEX identified with their XARG.
For this purpose, I suggest a lexical rule. It should probably be lexeme-to-lexeme, and also inherit from cat-change-only-lex-rule and no-ccont-lex-rule.
The mother of this lex rule has an NP or PP (as appropriate) on its SUBJ list, constrains the case of that NP or PP (as appropriate), and links the mother's SUBJ's INDEX to the INDEX of the element on the MOD list of the daughter. The mother should also be specified as [HEAD adj] and [MOD < >]. The mother should the same COMPS, SPEC and SPR values as the daughter. If you're using any other features in CAT outside those mentioned, their values should also be copied up.
Finally, you should declare a new feature, PRD, on the type head. Make the attributive (base) form of As/Ps [PRD -], and the derived predicative forms [PRD +]. Then edit the root condition to require [PRD +]. This will keep the [SUBJ <>, PRD -] attributive forms from serving as stand-alone clauses.
head :+ [ PRD bool ].
If an AP or PP stand-alone predicate has underspecified tense and aspect (i.e., can be used in any tense/aspect context) or if it actually takes tense/aspect markers directly, then you can allow for AP or PP predicates by redefining the selecting contexts. In particular:
Note that even if it is possible to use a copula for, e.g., past tense AP/PP predicate sentences, you might still have unrestricted tense/aspect on the copulaless counterparts of these sentences. The key question is whether the copulaless sentences are necessarily interpreted as having a particular tense/aspect value. If so, see the next section.
Finally, we come to the case of NPs used as predicates without any supporting verb. As with NPs used as the complement of a copula, we need to do something to get an extra predication in. Here, I think the best solution is a non-branching non-headed phrase structure rule which takes an NP daughter and produces a VP mother. It should introduce the "_be_v_id_rel" relation through the C-CONT.RELS, linking the C-CONT.INDEX to the ARG0 of this relation. If NPs as stand-alone predicates necessarily get present tense interpretation, this rule can also fill in that information.
If you also need a non-branching rule for tense-restricted PP or AP predicates, you might consider doing those the same way (VP over PP/AP), and sharing many constraints between the two rules. Note, however, that the PP/AP rule would have an empty C-CONT.RELS list.
Here are some sample MRSs to give you a sense of what we're looking for. Note that yours might differ in detail, because of e.g., different tense values or the use of a locative verb.
The child is happy.
<h1,e2:PRESENT:PROP-OR-QUES,
{h3:exist_q_rel(x4:uniq+fam+act:THIRD:SG, h7, h6),
h5:_child_n_rel(x4),
h8:_happy_a_rel(e2,x4)}
{h7 qeq h3} >
The child is in the park.
<h1,e2:PRESENT:PROP-OR-QUES,
{h3:exist_q_rel(x4:uniq+fam+act:THIRD:SG, h7, h6),
h5:_child_n_rel(x4),
h8:_in_p_rel(e2,x4,x9),
h10:exist_q_rel(x9:uniq+fam+act:THIRD:SG, h12, h11),
h13:_park_n_rel(x9)}
{h7 qeq h3
h12 qeq h13} >
The child is the winner.
<h1,e2:PRESENT:PROP-OR-QUES,
{h3:exist_q_rel(x4:uniq+fam+act:THIRD:SG, h7, h6),
h5:_child_n_rel(x4),
h8:_be_v_id_rel(e2,x4,x9),
h10:exist_q_rel(x9:uniq+fam+act:THIRD:SG, h12, h11),
h13:_winner_n_rel(x9)}
{h7 qeq h3
h12 qeq h13} >
For each of the following phenomena, please include the following your write up:
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).
tar czf lab6.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.)