📄 On parametering the choice of words in text generation and its usefulness in machine translation

Summary

The paper presents a knowledge-based interlingua machine translation system from French to Arabic for cooking recipes. Its focus is the generator and how it can phrase one conceptual meaning in several ways. The interlingua is the list of primitive actions that a cooking robot would execute. All linguistic knowledge is stored declaratively and read by dedicated interpreters, so language, word choice, word order and domain can each be "parametered":

• concept and word dictionaries
• semantic network structures
• ATN-style syntactic graphs
• morphology modules
• stylistic rules

Lexical choice depends on context. The concept dictionary looks at the ingredients involved before committing to a verb. Ten stylistic rules can each be switched on or off to produce shorter or more spelled-out texts.

Pure interlingua translation loses the shape of the source sentences. To recover it, the analyser records which stylistic constructions it saw in the French text and switches on the matching rules in the generator. This yields renderings that preserve both meaning and form. The same generator can also regenerate French, which shows that the design is multilingual across an Indo-European and a Semitic language.

Key points

• History. The French recipe analyser (M. O. Cordier, 1979) and the Arabic recipe generator (C. Moghrabi, 1980) came out of Université de Paris 6. They were combined into an MT system shown at ECAI'82. A multilingual version was presented at APICS 1985 in Halifax, and the system was later rewritten in C++ for the PC.
• Interlingua. The interlingua is a sequence of robot-executable actions such as PUTIN, PUTON, LIGHTSTOVE, WAITUNTIL and PUTWITH. For "Ajouter le sucre au lait chaud" it yields three valid outputs:
  • heat the milk then add the sugar
  • add the sugar to hot milk
  • dissolve the sugar in hot milk
• Knowledge modules. The semantic network uses typed structures (ACTION, CHANGE-OF-STATE, ELEMENT, QUALIF) with configurable slots. Syntactic graphs follow Woods' ATNs and are loaded from files. Arabic morphology derives adjectives and adverbials from verb roots.
• Stylistic rules. Ten rules cover pronoun use, object inversion, inserting "until" or "when", generalising verbs, factorising repeated verbs and objects, disambiguating adjectives, and merging location phrases. Each rule has a toggleable activator, and turning all of them on gives the most concise text.
• Fidelity strategies. Three were tried: passing the semantic network instead of the action list, grouping actions by source sentence, and recording the stylistic rules triggered during analysis. The first two produced sentence-by-sentence translation.

Interesting ideas

• I1. Argument-sensitive verb choice: The generator delays choosing a verb until it has consulted the dictionary entries of the arguments, so adding sugar to a hot liquid becomes "dissolve" while adding pepper becomes "to pepper". Keeping all candidates until style rules decide makes lexical choice context-aware and inspectable.
• I2. Stylistic rules as independent switches: Each aggregation or reordering rule (factorising, pronominalising, inverting, inserting connectives) is a separate rule with an on/off activator, so verbosity can be dialled from explicit to compact.
• I3. Recording source-form traces during analysis: When the parser passes a construction that matches a generation rule, it records that rule against the concept, so the target text can reproduce the original structure without abandoning meaning-based transfer.
• I4. Endpoint and duration features on verbs: The dictionary marks verbs as open-ended (stir), as reaching an end state (thicken, boil), or as quick (add). These marks license connectives like "until" and "when" and the reordering of events.
• I5. Grammar as data with one shared interpreter: Language-specific rewrite rules live in files, for example a verbless noun-phrase sentence for Arabic versus NP + VP for French, while the interpreter stays unchanged. Switching language then means swapping a file, not code.

For Mova

How these ideas could serve Mova, our small open language model — its files, stages and tests:

• I1 (back): Mova's generator could pick verbs by querying entity properties in the world model (state, location, substance type) and keep all equivalent candidates, logging why one was chosen.
• I2 (back): The text → graph → text compressor could expose each realisation rule as a toggle, making output length controllable and every surface change traceable to a named rule.
• I3 (back): Translation through the meta-world could attach construction tags (adjectival vs clausal, object order) to graph nodes so regeneration stays faithful to the source while still being driven by meaning.
• I4 (world): Mova's verb-class knowledge could carry similar aspect flags to help order events and infer when one action lasts until another's result holds.
• I5 (tree): UD dialect conversion and treebank-specific adjustments could be written as declarative rule files run by one interpreter, keeping each conversion auditable and easy to extend.