Add API for stating the source grammemes instead of using a SemanticConcept

[grhoten]

Right now, a lot of the code assumes that a given word is a lemma or makes assumptions about the grammemes of an ambiguous word. The current API just have a way to add constraints for adding the desired grammemes. We should consider adding API for adding such information to disambiguate the starting point in an inflection table.

For example, a given word may be masculine or feminine. When a word has 2 different meanings that depends on the gender, it can be hard to determine the right grammatical gender to use for the definite article. Such information has usually been disambiguated through a SemanticConcept, but there may be times that you want to use it in the current message without a SemanticConcept.

One possible path to implement such a change is to change InflectableStringConcept to provide some SemanticConcept functionality for stating the source grammemes for inflection. It would add some data to the DisplayValue. The various grammar synthesizers would need to start reading that data little more consistently though.

[anushka-cseatmnc]

Hi @grhoten ,I’ve been going through the issue #77 Add API for stating the source grammemes instead of using a SemanticConcept, and I believe I can contribute to it. I would love to work on designing and implementing the API for adding source grammemes to disambiguate inflection tables.

Would it be possible for you to assign this issue to me? I’m excited to start working on it and learn more about the inflection system. and will raise PR soon !!

Thank you!

Best regards,
Anushka

[grhoten]

Thanks for your interest. This would actually be a sizable change, and it's a nuanced feature enhancement. It would not be a good task for someone new to this project. There are easier tasks to work on that have a more immediate impact on getting the 0.1 release out the door, like getting the lexical dictionaries transitioned to using Wikidata as the source, or writing a script to automate such a task.

With that being said, here's why this issue is hard.

Right now, the constraints provide some ways to state which inflection pattern is desired. You can specify in the constraints that you want the noun inflection or the verb inflection. Take "brush" as example. The current constraint model allows you to differentiate between "1 brush/2 brushes" by interpreting it as a noun, and you can specify a verb for "she brushes/he brushes/it brushes/they brush".

In various languages, there are ambiguous scenarios where even specifying the part of speech is not enough. Take "стол" (pronounced as stol) and "стола" (pronounced as stola) as examples. If I want the plural of стола, is that originally the genitive singular form of стол, or is that originally the nominative singular form of стола? How would someone know which gender is supposed to be differentiate between these words? If the person did know the gender, then specifying the gender in the constraints can be confusing. Did you want to change the gender of the word, like many people do for adjectives and verbs in various languages? Were you trying to modify the desired gender, like in actor/actress, or were you specifying the current gender of the word? If I want to change стола to genitive, is it currently genitive, or should it be modified to be genitive?

While separating the constraints into something like context and target constraints, there would still be a question on how such a context should be specified. Should the source be a part of the DisplayValue provided to each language's grammar synthesizer implementation? That's a likely solution, but not all implementations take that into account right now. It still wouldn't be clear how to specify the context when such a word were provided as a plain string variable.

There would still be a question on how such data should be provided by an API caller. If it's a plain string variable, it's likely that the translator of the message won't have enough context to know the source beforehand. If it's up to the software developer to provide such context, that's going to be hard. Most software developers won't know that such distinctions are needed nor how to manage such data. If it's a hard coded string in a message, then a translator can provide such context. So this API would only be helpful if the translator knows the word during translation and not in a variable, and this project needs a conversation on the most effective way to handle this at a higher level issue.

In the end, this may be just adding an additional optional argument to the InflectableStringConcept constructor to specify the source constraints. That would be more convenient than using a SemanticConcept, and it would be similar to PronounConcept. Then the various grammar synthesizer implementations would need to respect that data more consistently.

[anushka-cseatmnc]

Hi @grhoten

Thank you for the detailed explanation and insights into the complexity of this issue. I now understand the deeper challenges involved, especially around disambiguating source grammemes and ensuring consistency across grammar synthesizers.

I appreciate your suggestion to start with easier tasks that contribute more immediately to the 0.1 release. Transitioning lexical dictionaries to use Wikidata or writing a script for automation sounds like a great way to get familiar with the project. I’d love to explore these areas—could you point me to any relevant documentation or issues that would be a good starting point?

That being said, I’m still interested in learning more about how InflectableStringConcept and the constraint model work, even if I don't take on this issue immediately. If there are any related discussions or documentation you recommend, I’d be happy to go through them.

Looking forward to contributing and learning from this project!

Best regards,
Anushka