📄 Attempto Controlled English (ACE)

Summary

Requirements specifications are usually written in free English, which is easy for everyone to read but often vague or ambiguous. Formal specification languages remove the ambiguity, but untrained users find them hard to read. Fuchs and Schwitter propose Attempto Controlled English (ACE) to bridge the two. ACE is a restricted English with a fixed set of function words, a user-extended lexicon of content words, and tight grammatical limits. Within the Attempto system, a deterministic parser builds a syntax tree and, at the same time, a discourse representation structure (DRS). The DRS covers the whole text, with each sentence interpreted against what came before. It can optionally be compiled into Prolog. The system then shows the user a paraphrase of how it read the input, answers questions posed in ACE by deduction, and can run the specification as a simulation. The prototype handles a non-trivial automated teller machine example. This shows that text which reads as English can serve as an executable, logic-backed specification that domain experts and developers can both check.

Key points

• The paper appeared at CLAW 96, the first workshop on controlled language applications. Its running example is an ATM called SimpleMat.
• Verbs are limited to active voice, simple present tense, and third person. Modal verbs and modal adjectives (e.g. possible, necessary) are excluded, and one-word verbs are preferred over particle verbs (start rather than turn on).
• The lexical editor has two interfaces:
  • Experts edit full feature structures.
  • Non-experts fill in templates. For a noun, they give number, gender, and whether it is countable or mass, and may add synonyms or abbreviations.
• The DRS uses nested IF/THEN and NOT sub-structures. A pronoun resolves to the nearest referent in a superordinate DRS that matches it in gender and number.
• In the Prolog translation, each condition becomes a fact/1 clause. Existential discourse referents are replaced by Skolem constants (0, 1, 2, …).

Interesting ideas

• I1. After parsing, the system restates the input in the same controlled language and marks every resolved pronoun, elided phrase, and synonym in brackets, so the user can see the reading at a glance.
• I2. Pronouns are resolved by a single transparent rule: take the closest referent in an enclosing structure that agrees in gender and number.
• I3. Wh-questions are answered by filling the found entity, in brackets, back into the question sentence itself, rather than returning a bare value.
• I4. A specification is executed step by step: events are printed as a trace, and missing situation facts (who the customer is, whether a code is valid) are requested from the user when needed.
• I5. When input is ambiguous, the system always picks one documented default reading and leaves other readings to explicit rephrasing, so its behaviour stays predictable.

For Mova

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

• I1 (back): Generating such a bracketed restatement from the meaning graph would give a human-readable check of every resolution step, and it doubles as a test for the text → graph → text path.
• I2 (frames): A deterministic, accessibility-based baseline like this would make each coreference decision easy to explain, and it can serve as a control against which learned resolvers are compared.
• I3 (answer): Answers to QA on fables or school tests could be returned as the completed question sentence, which shows exactly which entity filled which slot.
• I4 (world): The world-of-the-text builder could replay events in order and flag the facts it lacks, instead of silently assuming them, which exposes gaps in a story's state.
• I5 (tree): Fixing documented default attachments for known ambiguous constructions, and recording them in the explanation, would make parser choices reproducible and auditable.