Lexical rules and inputs with conflicting features

#1

I’ve generated some inferred grammars that don’t load because the input to a lexical rule has a feature that conflicts with the features that the lrt is assigning. Here’s how it usually happens:

  1. a pos tag is inferred incorrectly (either a projected INTENT tag or the issue we just resolved were a word had a two tags (eg. a verb and an incorporated noun) and Xigtreader created both a noun lexical entries)

  2. Mom creates a noun entry and lexical rule for the word that isn’t really a noun and has some agreement inflection (eg. second person)

  3. inference puts third person on all of the common nouns (anything that it doesn’t think is a pronoun)

I need to do some work in inference to safe guard against this, so that even if something goes wrong at (1), resulting in (2), (3) doesn’t make it so that the grammar won’t load. So I want to clarify what causes the grammar not to load.

A) Will the grammar not load if any input to a lexical rule has a conflicting feature or only if the sole input has a conflicting feature?

B) Is it safe to assume that only the immediate input clashing with the rule causes the grammar to not load (as opposed to the input to its input)?

I think the straightforward safe guard is to check the pcs that each “common noun” (scare quotes because this is an inferred common noun and might not really be a noun at all) is input to and if the pc contains an lrt with a person feature, don’t add third person to that common noun.

Depending on the answer to A, I may only need to do this if the pc only has one input. If B is not a correct assumption, I’ll need to look further down the chain for lexical rules.

#2

A lexical entry failing to unify with the daughter position of a lexical rule should not stop a grammar from loading — it will just stop that lexical entry from undergoing that lexical rule in any analyses.

If the conflicting constraint is on a type that gets unified onto the lexical rule’s daughter position as part of the definition of the rule, however, it will cause it to not load. I’m not sure how such constraints are handled in the matrix but I could imagine a lexical rule that is declared in the choices as able to accept inputs of a types A, B, or C, where (say) B is actually statically ununifiable with the information in the rule. That would require a super type A-or-B-or-C which would not have the offending constraint and therefore the grammar would load. If only B were listed as possible in the choices, on the other hand, no such super type would be needed and hence, depending on how such a system is implemented, you could get a grammar load failure. Again, I’m not sure if the matrix actually operates this way?

Best, Woodley

#3

Correct – the way the morphotactic system in the Grammar Matrix customization system works, if there is only one possible input for a position class (lexical type or other position class) then the position classes input (daughter) is constrained to be a sign of that type. So, for example, a lexical rule that takes only intransitive verbs as input will be constrained to take intransitive-verb-lex as its daughter. If that same rule tries to e.g. put agreement features on the verb’s object (necessitating a non-empty COMPS list), you get an ill-defined type and the grammar won’t load.

If there are multiple inputs to a rule (and assuming these don’t have a mutual supertype with no further subtypes not in the set), then the customization system posits an additional type, with the suffix -lex-rule-dtr, that all of the possible inputs inherit from. But this type won’t bear any constraints of its own, so any constraints on it that clash with the daughters will only be discovered at parse time, rather than compile time.

#4

Thanks both! These explanations are really helpful. This is very similar to the issue we had with intransitives… that’s why I wanted to assume B) but I couldn’t remember why I thought that was the case.

Perfect. Sounds like my plan should work then!