Computational Study of the Hebrew Bible

1 · History of biblical indexing before generative AI

Indexing the Hebrew Bible is one of the oldest information-retrieval projects in Western scholarship. The lineage runs from hand concordances to morphological databases long before any neural model.

Concordances

• Isaac Nathan ben Kalonymus, Me'ir Nativ (c. 1440s) — the first concordance of the Hebrew Bible, organized to locate every occurrence of a word. Built as a tool for disputation, it established the verse-plus-wordlist model.
• Solomon Mandelkern, Heikhal ha-Kodesh (1896) — the standard critical Hebrew concordance for a century, organized by root, listing occurrences with grammatical context.
• Abraham Even-Shoshan, A New Concordance of the Bible (1977–80) — the modern scholarly standard, organized by lemma under root, distinguishing senses. Still a benchmark for lemma/root organization.
• James Strong, Exhaustive Concordance (1890) — the English-facing lineage. Every Hebrew and Greek word received a Strong's number, a stable identifier keying an English concordance to a Hebrew/Greek dictionary. Strong's numbering remains the connective tissue of most open datasets today.

Lexicons

• Gesenius, Hebräisches und Aramäisches Handwörterbuch — the 19th-century root of modern Hebrew lexicography.
• Brown–Driver–Briggs (BDB, 1906) — root-organized English lexicon, public domain, still embedded in open tools via Strong's links.
• Koehler–Baumgartner (HALOT) — the leading modern critical lexicon (copyright, not open).
• Semantic Dictionary of Biblical Hebrew (SDBH), United Bible Societies / de Blois — organizes vocabulary by semantic domain rather than gloss. Its data flows into the open MACULA dataset.

Text editions

• Masoretic Text (MT) — the received Hebrew/Aramaic text with vowel points (niqqud), cantillation (te'amim), and marginal Masorah, standardized by the Masoretes (Ben Asher school) between roughly the 7th and 10th centuries CE.
• Leningrad Codex (B19A, 1008 CE) — the oldest complete MT manuscript, the base of most printed and digital editions.
• Biblia Hebraica Stuttgartensia (BHS, 1977) — the critical print edition of the Leningrad Codex with a text-critical apparatus. Biblia Hebraica Quinta (BHQ) is the in-progress successor.

Early digital text systems

• Humanities computing itself begins with Roberto Busa's Index Thomisticus (Aquinas, from 1949), which set the paradigm of a machine-readable, lemmatized corpus.
• The Michigan–Claremont–Westminster electronic transcription of BHS (transliterated encoding) was the first widely shared machine-readable Hebrew Bible, from the 1980s.
• The Groves Center / Westminster Hebrew Institute produced the Westminster Leningrad Codex (WLC) with hand-verified morphology, still the backbone of open datasets.
• The ETCBC (formerly Werkgroep Informatica, Vrije Universiteit Amsterdam), under Eep Talstra, began building a clause-level linguistic database of the Hebrew Bible in the 1970s.
• Query engines followed: Emdros (Ulrik Sandborg-Petersen) with its MQL topographic query language powered Bible software and the ETCBC data for decades.

Takeaway for system design: the concordance/lemma/root/Strong's model is not legacy baggage. It is the exact data shape a modern index needs, and open datasets already encode it.

2 · Core text resources (what they contain, how they are structured)

Uncertainty flag: exact word counts, version numbers, and license details drift between releases. Treat the figures here as close and pin a specific dataset version at ingestion time.

3 · Current AI and machine-learning work that is usable

A key finding: for the Masoretic Text specifically, hand-verified morphology already exists, so machine morphological parsing is mostly unnecessary for the MT itself. ML earns its place on harder tasks: reconstruction of damaged inscriptions, semantic search, stylistic classification, and candidate intertextual detection. The tasks below are ordered by how reliable and ready they are.

Named projects worth tracking

• Dicta (Israel Center for Text Analysis) — nonprofit, open-source Hebrew NLP. Tools: Nakdan (automatic diacritization across modern, rabbinic, poetic Hebrew), DictaBERT models (including morphology), BEREL (rabbinic-Hebrew PLM), and Tiberias (stylistic comparison and classification over Bible datasets). Strongest applied ML in this space, though its core training leans rabbinic/modern rather than biblical.
• ETCBC — beyond the database, publishes ongoing computational-analysis research and the Text-Fabric tooling that makes the data programmable.
• Sefaria — open Jewish-text library with a public dataset (~26 GB) and a Linker API that auto-detects Tanakh citations in arbitrary text. The single easiest source of traditional intertextual links.
• Transformer intertextuality benchmark (arXiv 2506.24117, 2025) — a systematic study of transformer models for detecting parallels in biblical Hebrew. Useful as a method reference for a candidate-generation layer.

Caution on general LLMs: peer commentary (e.g., HIPHIL Novum, 2024) documents that large language models hallucinate morphology, invent citations, and misparse biblical Hebrew. They are unsafe as a source of linguistic truth and should be confined to explanation over retrieved, verified data.

4 · Do existing systems preserve Hebrew structure?

The dividing line is whether a tool keys its analysis to the Hebrew token or to an English gloss.

• Preserve well: ETCBC, MACULA, OSHB, and STEPBible key every annotation to the consonantal Hebrew word, its lemma, and its morphology. Roots, binyanim (verbal stems), person/gender/number, and construct relationships survive. ETCBC preserves the most grammar, including phrase function, clause type, and valence.
• Partial loss: consumer Bible apps that route everything through Strong's glosses can flatten lemma vs root (a lemma is a dictionary word; a root is the underlying tri-consonantal skeleton), and often simplify syntax to interlinear word order.
• Real gaps: automatic root derivation is not uniform — OSHB gives lemma, and mapping lemma to root needs an explicit table (weak roots and geminates make this non-trivial). Cantillation-based phrasing, and the semantics of the binyan system, are rarely modeled outside ETCBC/MACULA.

Design implication: build on a Hebrew-native dataset (OSHB or MACULA), store lemma and root as distinct fields, and never let an English gloss become the primary key.

5 · A structured index and simple knowledge graph

Keep the core graph small and fully derivable from existing verified data. Every node and edge below can be populated from OSHB or MACULA on day one, except the two marked optional.

Node types

Edges

This is deliberately shallow. It answers the questions that matter (where does this root occur, in which stems, near which entities, with what parallels) without trying to encode every interpretive layer at once. Deeper syntax (the ETCBC/MACULA trees) attaches later as an additional edge set, not a rewrite.

6 · Interpretive traditions as optional layers

Jewish and Christian reading traditions matter for data modeling only where they change annotation. Model them as separate, provenance-tagged layers over the same core text, never merged into it.

• Belongs near the core (textual, not interpretive): qere/ketiv variants and the Masoretic paragraph divisions (petuchah/setumah). These are part of the received text and should be first-class.
• Optional Jewish layer: weekly parashah / triennial seder divisions, traditional cross-references, and links out to rabbinic commentary (Sefaria supplies these with an open API).
• Optional Christian layer: chapter/verse versification differences, canonical ordering (Tanakh vs Old Testament sequence), and typological or New-Testament citation links.

Each layer is a toggle. The core index stays neutral and verifiable; interpretation is clearly attributed to its tradition and source.

7 · Speculative structures (codes, numerics)

Equidistant-letter sequences, gematria patterns, and "hidden design" claims lack methodological support: they are sensitive to text edition, spacing, and multiple-comparisons problems, and published statistical support has not withstood scrutiny. They are deprioritized and must never sit in the core. If ever included, they belong in a clearly labeled, opt-in computed layer, presented as pattern output rather than fact, and kept separate from the verified linguistic data.

8 · Next-generation system design

A verified text, morphology, and basic linguistic annotation, made queryable two ways, with every answer traceable to the token and dataset it came from.

• Structured queries (deterministic): "all Qal perfect 3ms verbs of root ק־ט־ל in the Torah" runs as SQL/graph traversal over verified fields. No model in the loop, fully reproducible.
• Simple natural-language questions (controlled): an LLM translates the English question into a structured query, the database executes it deterministically, and results return with citations. The model plans the query; it never invents the answer.
• Explanation (retrieval-augmented): to explain a result, the system retrieves the relevant verses and lexicon entries and asks the LLM to summarize only that retrieved, cited material.

Every response carries the verse reference, the exact Hebrew token(s), the morphology, and the source dataset plus version. If it cannot be traced, it is not shown.

9 · Core technologies

• Relational database (PostgreSQL) for the token-and-feature core. Structured linguistic queries are set operations over columns and are fast, exact, and reproducible here.
• Graph layer for relationships (root families, entity co-occurrence, parallels). Either a native graph DB (Neo4j) or graph queries inside Postgres. Text-Fabric serves as the ingestion source for ETCBC-derived structure.
• Retrieval (RAG) only for explanation: embed verified verses/lexicon entries, retrieve by relevance, and let the LLM summarize the retrieved set with inline citations.
• Generative AI is fenced to three jobs: translate an English question to a query, summarize retrieved verified text, and phrase an explanation. It is never the source of morphology, lemmatization, or textual claims — those stay deterministic.

10 · Accuracy safeguards

• Traceable citations: every fact links to verse + token + dataset name + version hash.
• Data / interpretation separation: verified linguistic data and model-generated or tradition-specific annotation are stored in different layers and visually distinguished in the interface.
• Confidence flags: any ML-derived edge (a candidate parallel, a proposed entity link) is labeled as such and ranked, never presented as settled.
• Human review: new annotation layers pass expert review before promotion from "candidate" to "accepted."
• Determinism first: if a question can be answered by structured query, it is — the LLM path is a convenience, not the authority.

11 · Development plan (working prototype first)

12 · Comparison of leading tools

Reading: Logos and Accordance are references to consult, not foundations to build on (closed data). MACULA, ETCBC, OSHB, and STEPBible are the buildable foundation — open, documented, and Hebrew-native, with an English presentation layer that is entirely your own to design.

13 · Blueprint and research questions

The blueprint in one view

• Data core: MACULA (or OSHB) → PostgreSQL, tables for book/chapter/verse/word/lemma/root/morphology, plus an entity table and a parallels table.
• Graph layer: root families, entity co-occurrence, verse parallels (Sefaria + flagged ML candidates).
• Query surface: deterministic structured search + controlled English natural-language questions that compile to structured queries.
• Explanation: RAG summarization over retrieved, cited, verified text only.
• Interface: all English; Hebrew shown as data, every result traceable to token + dataset version.
• Governance: data/interpretation separation, confidence flags, expert review, optional tradition layers as toggles.

Concrete research questions such a system could investigate

• How does the distribution of a given root across verbal stems differ between the Torah, the Prophets, and the Writings?
• Which lemmas show markedly different collocations (neighboring words) between narrative and poetic books?
• What are the strongest candidate intertextual parallels for a chosen passage, ranked by evidence and confirmable against traditional cross-references?
• How do named entities co-occur across books, and what does the co-occurrence network reveal about narrative structure?
• Where does qere/ketiv variation cluster, and does it correlate with particular grammatical environments?

Bottom line: the verified linguistic foundation already exists and is open. The realistic, high-value work is integration and interface, using deterministic methods for everything linguistic and confining generative AI to explanation over cited data.

14 · Sources

• ETCBC / BHSA (Text-Fabric) · ETCBC data · SHEBANQ · ETCBC: recent computational developments
• Open Scriptures Hebrew Bible (morphhb) · OSHB overview
• STEPBible-Data (TAHOT / TBESH) · STEPBible data site
• Clear-Bible MACULA Hebrew
• Dicta (organization) · Nakdan diacritizer paper · NeoDictaBERT (2025)
• Sefaria Linker API · Sefaria data export
• Intertextual parallel detection in biblical Hebrew (transformer benchmark, 2025) · Embible: reconstruction of ancient Hebrew/Aramaic (2024)
• LLMs and biblical Hebrew: limitations (HIPHIL Novum)
• Awesome Bible developer resources

Confidence: high on the identity, structure, and openness of the core datasets (verified against their live repositories, July 2026). Medium on fast-moving ML details (model names, accuracy figures, latest releases) — verify the specific version before relying on it in a build.