📄 An Expert System for Automatic Reading of A Text Written in Standard Arabic

Summary

The paper describes a text-to-speech (TTS) system for Standard Arabic built as a rule-based expert system. It has two parts: a recorded sound database and a pipeline that turns written text into audio. Input text is first normalised, which covers composite characters, numbers, dates and abbreviations. An exceptions lexicon then handles words that the general rules would mispronounce. A Phonetic Orthographical Transcription (POT) stage maps graphemes to phonemes using context-dependent if/then rewrite rules that work directly on Arabic characters, with no deeper morphological analysis. The sound units are phonemes and diphones. The diphones come from nonsense carrier words (logatomes), and the recordings were segmented by hand in PRAAT. Speech is produced by concatenating the stored units. The authors tested the system on a reference sentence set chosen to cover the language's typical combinations and report an overall success rate of about 96%. The work shows that a transparent rule system acting directly on graphemes can give understandable Arabic speech for limited vocabulary.

Key points

• The pipeline runs in this order: acquisition, pre-processing and normalisation, exception lookup, grapheme-to-phoneme transcription (POT), and concatenative synthesis from a sound database.
• Each rule has the form [Phoneme] = LeftContext + Character + RightContext.
  • Boundary markers are # for sentence start, $ for sentence end and § for word end.
  • Consonant classes in the rules include solar and lunar consonants.
• Units were segmented manually in PRAAT, and the sound database was modelled as a UML class diagram.
• The success rate is the number of correctly pronounced phrases divided by the number of phrases tested, times 100.
  • The overall figure is about 96%.
  • Results are also broken down by category: short and long vowels, solar and lunar consonants, isolated words, sentences, numbers and exception words.
  • The per-category figures range from roughly 75% to 100%.
• The system compares phoneme-based and diphone-based synthesis. Its input is vowelled Arabic script plus simple numeric expressions.

Interesting ideas

• I1. Each context rule rewrites one character based on its left and right neighbours, and an exceptions lexicon is checked before any rule fires, which keeps the rules simple and every output traceable.
• I2. Rule contexts include explicit markers for word end, sentence start and sentence end, so position-sensitive behaviour is written directly into the rule.
• I3. Logatomes are carrier words built to contain exactly one target unit, so each unit is captured apart from confounding context.
• I4. The test set was picked to cover the language's characteristic combinations, and scores were reported per phenomenon category rather than as one number.
• I5. Before transcription, numbers, dates, abbreviations and similar items are rewritten into a fully literal, disambiguated form.

For Mova

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

• I1 (tokens): Lemma and morphology rules in crate en could check an explicit exception list first and log which context rule produced each analysis, so every lemma has an explanation.
• I2 (tokens): Tokenizer and tagger rules could refer to boundary symbols explicitly instead of hiding position checks in code, which makes rules for sentence-initial or word-final cases readable.
• I3 (learn): Probe sentences that each isolate a single phenomenon, such as one attachment ambiguity, would make good negative controls and pinpoint which repair rule or witness parser fails.
• I4 (answer): School-test and fable QA evaluation could be broken down by phenomenon class (negation, quantities, coreference), so a regression shows up in its own category.
• I5 (back): The generator could run the reverse normalisation step, turning numeric and date values from the world graph into spelled-out text under explicit, inspectable rules.