📄 QuranTree.jl: A Julia Package for Quranic Arabic Corpus

Summary

The Quranic Arabic Corpus annotates every segment of every word of the Qur'an with part of speech, morphology, an ontology and dependency syntax. Until now its official programmatic access has been the Java library JQuranTree. That language is a hurdle for many humanities researchers. Meanwhile, existing high-level packages such as quRan for R and PyQuran for Python omit the corpus's morphological layer. The author builds QuranTree.jl, a registered open-source Julia package around three goals: speed, robustness and modularity. It provides:

• indexing by chapter, verse, word and word part
• Buckwalter and user-defined transliteration that converts back and forth with Arabic script
• Simple Encoding
• dediacritization and normalization for both scripts
• a complete type system for all morphological tags

Julia's optional typing and multiple dispatch let users write wrappers that reject wrong inputs. PyCall.jl and RCall.jl give access to tools in other languages, shown with TextAnalysis.jl and CAMeL Tools. The paper also sets up a speed comparison against CAMeL Tools, but its results fall outside the extracted text. The resource lowers the barrier to linguistic study of Quranic Arabic, which differs markedly from MSA.

Key points

• The corpus covers 77,430 words of the Qur'an. JQuranTree's object model nests Document → Chapter → Verse → Token → Character → Diacritic and uses extended Buckwalter encoding.
• Raw morphology strings such as STEM|POS:N|LEM:...|ROOT:smw|M|GEN are converted with parse(Features, x) into typed objects. These can then be checked with isfeature(parsed, Masculine).
• Every tag from Dukes and Habash (2010) is an immutable Julia struct placed in a type hierarchy. For example, verb moods sit under AbstractVerb, so a method written for the parent applies to all its subtypes.
• Interoperability is demonstrated in two ways:
  • TextRank summarization of Chapter 18 (The Cave) via TextAnalysis.jl.
  • CAMeL Tools disambiguation of a dediacritized basmala, called through PyCall.jl's @pyimport.
• The planned speed test chains three steps on the Uthmani corpus: transliterate to Buckwalter, dediacritize, then encode back to Arabic. It compares QuranTree.jl against CAMeL Tools.

Interesting ideas

• I1. Morphological tags are modelled as a typed hierarchy instead of opaque strings, so code can target one tag or a whole family and wrong inputs are caught early.
• I2. Annotation strings are parsed once into a structured object and then queried with simple predicates instead of repeated string processing.
• I3. A round trip of script → transliteration → dediacritized → script serves as a single end-to-end task that exercises every conversion function at once.
• I4. The core stays minimal ("nuts and bolts"), and missing capabilities are borrowed from other ecosystems through thin bridges rather than reimplemented.
• I5. Raw source datasets are exposed only as read-only arrays, so analysis code cannot silently alter the reference data.

For Mova

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

• I1 (tokens): UD FEATS and UPOS in crate en could become enums grouped under traits like "verbal feature", so tagger and lemmatizer code matches on types rather than strings.
• I2 (tree): treebank loading and UD dialect conversion could parse FEATS/MISC once into typed records and filter sentences with predicate queries, making conversion rules more explicit.
• I3 (back): the text → graph → text compressor could use a similar chained round trip as a standard regression and speed benchmark that flags lossy steps.
• I4 (learn): external parsers could join the silver-data witness pool through thin adapters, keeping Mova's own core small while gaining more independent voters.
• I5 (world): compiled knowledge such as WordNet/FrameNet/Wikidata tables could be loaded immutably, so each text's world model builds on an unchanging, auditable base.