Currently there is no way to specify determiner-noun agreement via the Morphotactics page (and I checked, and it does not look like such agreement is implicitly assumed by the customization system).
But determiners do agree with nouns in many languages, so I am assuming this is because nobody ever got to it and not because there is some reason not to do it?
(Asking because I am working on question determiners now, to double check that I am not missing something in the customization system by not filling out the questionnaire correctly).
Hold on, this should take care of PNG:
basic-determiner-lex := no-ltop-lex-item &
[ SYNSEM [ LOCAL [ CAT [ HEAD det,
VAL.SPEC.FIRST.LOCAL.CONT.HOOK [ INDEX #ind,
LTOP #larg ]],
CONT [ HCONS <! qeq &
[ HARG #harg,
LARG #larg ] !>,
RELS <! relation !> ] ],
LKEYS.KEYREL quant-relation &
[ ARG0 #ind,
RSTR #harg ] ] ].
But something like CASE we still need to be able to add (via the questionnaire), right?
Any features you add to determiners on the Lexicon page (not Morphology) are actually assumed to be features of the noun the determiner combines with. This includes PNG as well as case.
So, the assumption is that I add determiners as full-form entries? But is that reasonable for languages where determiners (such as which) follow a regular inflectional paradigm for number, gender, and case? I would need to add 4*6 full-form entries for the Russian which, technically (though admittedly there is some syncretism and so it is actually 10 distinct forms. But it’s not just which).
Yeah – we don’t have any inflection for determiners in the customization system. Even if you have large paradigms, is there really any gain in treating them as inflection? That is, are there multiple stems that go into the same paradigm? (If so, then you can do this in tdl editing, but the customization support isn’t there.)
We have inflection, actually, but not agreement with nouns.
Yeah, all which things inflect like adjectives, and there is more than one (and perhaps I could even allow them to use the adjective position class?.. not sure). There is a how-many that also inflects using the same paradigm.
Since I am adding a new type for question determiner to the questionnaire, I can add customization support for agreement, too.
I think using the adjective position class wouldn’t work unless you actually treat them as adjectives. Those constraints end up on the MOD value, not the SPEC value.
Now that you point to the inflection for determiners, I wonder if that isn’t actually agreement. What happens if you put a CASE or PNG value in? My guess is that it would end up on the SPEC, not on the determiner itself.
Right, that’s exactly what I was hoping for and now that I retested it with a tiny grammar I see that that’s indeed the case! Makes perfect sense, hooray.
I wonder why I had an issue with my Russian grammar that I had to add things by hand; must be a combination of issues (like starting with a wrong type and only later converting it to determiner manually).
I’d like to revive this topic for a bit. It appears this isn’t fully working in the customization system, and I’d like to have it working for my Russian extended regression test (for determiners like which).
I am suddenly confused about what should enforce the agreement :).
- The noun has CASE and PNG values; that much is clear.
- The determiner can inflect for CASE and PNG; should the lexical rule put the constraints on (a) the determiner’s SPEC; (b) the determiner itself; (c) both?
- The determiner can be daughter to (a) the head-specifier rule; (b) the determiner-extraction rule; (c) the filler-gap rule. Should all three rules say something about CASE and PNG, then?
I believe that the combination of 2-c and 3-b (in addition to 1, of course) works, but I am not sure that’s the canonical analysis. Perhaps what I should be doing is 2-a and 3-abc?
So, no it does not, if you have both inflecting and noninflecting determiners, e.g. ``I see many books’’ , many books in Russian should be [ CASE acc ] but books should be genitive.
Also, analysis 2-a probably makes 3-a unnecessary. Back to square one trying to understand why this bit isn’t working yet, because the customization system already has 2-a :).
Oh, the problem probably is that the extracted-determiner-phrase is constraining the wrong thing on its SLASH-ed element. Or indeed that, for some reason, I didn’t write it to identify the entire LOCAL substructures between the SLASH and the SPR.
Oh, that’s what I meant, sorry. But the extraction rule should put the right thing on the SLASH…