📄 SimpleNLG: A Realisation Engine for Practical Applications

Summary

Gatt and Reiter present SimpleNLG, a Java library for English surface realisation. It deliberately handles only the mechanical part of generation: building syntactic structure, inflecting words and linearising the result. Deciding how semantic content maps to syntax is left entirely to the developer. The authors argue that wide-coverage realisers such as FUF/SURGE, KPML or OpenCCG impose a fixed input formalism, can become slow when they search large spaces of choices, and are difficult to adapt to domain sublanguages such as weather or patient-data summaries. SimpleNLG instead exposes an API in which a developer creates constituents, sets features (tense, interrogative type, passive, etc.), combines phrases and hands the result to a lineariser. Canned strings and fully specified phrases can be mixed freely. Its morphology reimplements the MorphG rules, and it can draw lexical information from the NIH Specialist Lexicon. The engine grew out of large data-to-text projects. It matters because it gives application builders predictable, fine-grained control over output without requiring them to adopt a full generation grammar.

Key points

• The library is written in Java, targets English, and was published at ENLG 2009 (pp. 90–93). It was motivated by data-to-text systems that summarise numeric and symbolic data, where efficiency and sublanguage constraints are central.
• The lexical component (Lexicon, MorphologicalRule, LexicalItem) reimplements the MorphG inflection rules, covering regular and irregular forms. It is kept separate from the syntactic component.
• The distribution can connect to a database built from the NIH Specialist Lexicon, which holds more than 300,000 medical and general-English entries.
• The syntactic layer includes several key types:
  • HeadedPhrase and CoordinatePhrase, with recursive coordination;
  • PhraseSpec subtypes such as SPhraseSpec, NPPhraseSpec and VPPhraseSpec;
  • StringPhraseSpec for canned text.
• Features such as Tense, Number, Person, Mood, Passive and InterrogType drive the output. For example, setting a WH-type linked to the object turns a declarative into a "where" question.
• Lexical features such as adjective ordering position and noun agreement type are stored in the lexicon. At the time of writing, however, the realiser did not apply them automatically.

Interesting ideas

• I1. Split realisation from tactical choice. Offering only the "mechanical" layer lets each application keep its own domain logic for content-to-syntax mapping. This suits projects with strict style or sublanguage needs.
• I2. Mix templates and grammar in one tree. Fixed fragments can be stored as plain strings next to fully built phrases. A system can then start template-based and gradually replace parts with generated structure, without changing tools.
• I3. Degrade gracefully instead of failing. Incomplete or ill-formed structures produce awkward but readable text rather than a crash. This is a sensible priority for production systems running on messy input.
• I4. Make morphology usable on its own. Because the inflection module is separate, it can be used without the syntax layer, for example to inflect slot fillers correctly in templates. This idea is especially useful for richly inflected languages such as Ukrainian.
• I5. Express variation as feature switches. Questions, tense or passive voice are produced by changing a feature on an existing structure rather than rebuilding it. This keeps generation code compact and makes systematic variants easy to produce.