Force a variant form in an affix template

Jeff, Andreas,

I don’t have time to look into this at the moment, but I wonder if the Stem Name feature in FLEx will accomplish what you’re wanting?

FWIW,

To view this discussion on the web visit https://groups.google.com/d/msgid/flex-list/ba056898-c8af-1216-7ddb-2362643d9a07%40sil.org.

I had an off-list email exchange with Andy, but I think it’s probably worth sharing on the list, so I include it below.

Andy’s proposed solution involves an “ugly trick”. And it’s pretty ugly… Furthermore, I can’t really lose my variants, because they are what allow me to have reasonable dictionary entries. E.g. the “iziid” continuous form is required for parsing so I can add a prefix to form niziid, tiziid or yiziid, but the citation form needs to be yiziid. I don’t think I can do that (have a citation form) with an allomorph. But Andy is suggesting adding allomorphs to get that parsing behavior. (But we then don’t want the variant to match in the parse, hence the ugly trick of inserting a non-breaking space. That is not only ugly, but would be difficult to do and to maintain data consistency.)

So my question is, should we be working towards making variants work better with the parsing? Maybe having features which allow them to be included or excluded in affix templates? I realize that this is not a simple proposition and would take a significant amount of time, but it seems like a number of people keep running up against this limitation, so maybe we should have that as a goal.

Your thoughts?

Jeff

Hi, Jeff.

First, thank you for the great description of the issue and the project file.  That was *very* helpful.

I've played with this some and it looks like the parser is not designed to use variants in this way.  Variants work great if the irregularly inflected form includes one or more inflection template slots (and the features of a member of those slots).

So what to do?

I got something to work, but it involves an ugly "trick" if you really need to use variants (e.g., for the dictionary).  First the results:



Here's how to get these:

Add a new inflection feature for non-imperative under mood.  I did this by hand.

The idea here is parallel to having two values for aspect so that we don't get completive affixes on continuous forms.  It's just that imperative is a mood so we can't use aspect.  I'm also assuming that the continuous and completive forms are good with moods other than imperative.

Next is to use Stem Names.  These are what the parser is designed to use for this kind of situation where there is stem allomorphy based on sets of features.  Edit the Stem Names under Verb to include a new Completive one and to make sure we use a fuller set of features for completive, continuous, and imperative.  Here's what I have:





Notice the use of the mood:-impr feature.

Next is to add the allomorphs in the lexical entry for continuous and imperative and to mark all three forms with their stem names.





Then we need to adjust the affixes for features.  We do not use any required features at all.  The null Sg has this Grammatical info:



The null 3S.Masc has


The -i SgFem has


and so on.

Finally, here's the ugly trick, assuming you want to keep the variants as they are for the dictionary.    The parser still finds the variants and proposes bad parses (and basically duplicate parses).  So what can be done to block them from being seen by the parser?  The trick is to insert a zero-width space (x200B) somewhere inside the variant.  It won't show for the dictionary but the parser will not match the variant because it has this space character in it and the input word does not.

I hope this is helpful (and I may have done something else that I'm not remembering - if so, just ask and hopefully I'll remember or we'll figure it out).

--Andy

On 2/9/2022 3:23 AM, Jeff Heath wrote:

Hi Andy,

We are just finishing up our Outilingua French language technology workshop, so I don’t have much time to wrap my brain around this problem right now… But attached is a backup of the database. (It is also a shared database, but I would prefer that you play around with an independent copy from a backup.)

The playing around I have done on this problem is with the word zaad (to add):

Under Texts and Words, check out the text “zaad forms”. That gives you an idea how this verb works:

The first line is Perfective/Completive forms (Note that the second word had chosen the wrong homograph in the backup you have, I believe…)

The second line is Imperfective/Continuous forms

The third line starts with 2 imperative forms, then a couple of words I was playing with

That first imperative word can also be analyzed as Completive:

That should not be. “ziid” is an imperative variant of zaad(1), and we need to find a way not to allow it to appear in the BASE slot of anything but the Imperative affix model. (So CompPersNum slot shouldn’t be allowed with an Imperative base.)

The third word is ‘ziidan’. It also should only be imperative, but the parser offers a Completive form as well.

The fourth word is ‘zaadi’. It uses the Completive base, so it should not offer an imperative form (since it doesn’t use the imperative base ‘ziid’), but it does (3^rd entry):

So there also needs to be a way to prevent an ImprNumGen slot affix from being used by a Completive base form.

Thanks for your thoughts and input,

Jeff