Non-Technical Description of DB1-DB7

• The purpose of the DB is to prove with data, if what I suspect is consistent with reality.

• The direction of each DB could vary based on the information I find.

• I am not sure I can do this, each stage will provide more clarity and help me to understand if the next is possible.

• Below is the framework or roadmap – I do not have the details of how I will actually “do” any of this, I figure it out as I go.

• Current Status:

  • In DB1 – there are 3 separate datasets that make up DB1, I have dataset A and C started.

• Difficult for others:

  • Obvious ridiculousness of a single researcher “fixing” the OT

  • Difficulty seeing text as dataset rather than ideological support beam

  • Exposes infallibility as myth

  • Exposes doctrinal imprints or overlays on Hebrew texts

  • If the bible fell out of the sky in English, sprinkled with magic fairy dust, then this project is useless

  • If “God is more powerful” then the translators and meaning can somehow be mystically imparted to reader without accurate translation, then again this project is useless

 

 

DB1 — Text Backbone – DB1 will be in the DB7 – full loop – we end where we start

• DB1 – OSHB Token Mirror

• Goal: Clean, auditable mirror of OSHB (WLC) at the token level.

• Input: OSHB XML (WLC, lemma+morph+text)

• Output: 39 CSVs, one per OT book, one row per <w> token

• Key fields: book, chapter, verse, token_in_verse, lemma, morph, hebrew_text, osis_id

• Controls: no cleaning, no Strong, no interpretation — pure extraction with file + run metadata

• This is the spine. Every other DB attaches here.

  • NEED: researcher wanted a database where she could type in EITHER the Strong’s number OR the English translated word and pull up every instance in the Old Testament for analysis. For example, type in “god” and see how many unique Hebrew words (with Strong’s reference number) were translated as “god.” She wanted whole OT in excel to analyze text as dataset.

  • SUSPECT: The English translation of some Hebrew words is inconsistent.

  • GOAL: Old Testament Research tool:

    • built for analyzing the text as data

    • Can search  Old Testament Re

  • PLAN: DB1 has 3 datasets that make it up. Each dataset provides different data element(s)

    • Dataset 1A: A mirror extraction of Open Scripture Hebrew Bible (OSHB) for every token (word, punctuation), of the below fields for the 39 books in the Protestant OT. The OSHB is public domain, meaning I can publish their data in a new way without copyright infringement.

      • 1A.1 Verse Identification (Example Genesis 1:1): OSHB follows the XXXX

      • 1A.2 Hebrew word: In modern Hebrew characters per the Leningrad Codex circa 1008 AD – Oldest standardized version of the Hebrew texts as presented in Jewish Tankah and Protestant OT

        • For reference the Leningrad Codex is 5000+ years after creation, and 1400 years after the last book of the Old Testament is thought to have been written.

      • 1A.3 Lemma: Strongs number identification corresponding with Hebrew word + OSHB internal reference. Strong’s numbering system published in 1890.

      • 1A.4 Morphology: The grammar of each word as done by OSHB.

      • 1A.4 untouched and untransformed – this links the Strong’s number (number assigned to Hebrew word) to the Hebrew word. Strong’s numbering done approximately 1890 AD (relatively new).

    • Dataset 1B: Transliteration of Hebrew word, which means to translate the Hebrew word into how it would sound in English. Researcher will do with GPT help by assigning consistent Latin (used in English) letters to Hebrew characters (no public domain issue bc proprietary).

      • 1B.1 Hebrew word transliterated in English

    • Dataset 1C: English translation of Hebrew word as used in the “bible.” This is not the definition, this is the as translated into English in an actual bible verse. Translations vary so not all bibles will agree. Researcher to create using WEB public domain version.

      • 1C.1 How the Hebrew word was translated in the WEB public domain bible

  • All public domain or researcher created, meaning researcher can publish and give freely

  • The last DB, or DB7, will contain all of the fields in DB1, PLUS a new numbering system (similar to Strong’s

​

Summary — Dataset 1C Strategy (as discovered today)

• (Clear, structured, future-you-readable. Copy this somewhere safe.)

• Goal:

• Create a unified, public-domain-safe English token column aligned to Hebrew Strong’s — not meaning-restored, just current English equivalent, reproducible, defensible, traceable.

• Phase 1 — Base Dataset

  • Use BH dataset (DB1) as the English token source.

  • Each row already has Strong’s, Hebrew, English token, verse reference

  • Will become the scaffold for 1C

• Phase 2 — Compare English Token vs Public Domain Verse

  • Public domain target likely WEB (or KJV as secondary check).

  • Automated check:

  • For each verse:

  • Build verse text maps for both:

  • BH tokenized English words (per Strong)

  • WEB verse words (flat sentence)

  • Check if BH English token exists anywhere in WEB verse wording.

  • Output:

  • Strong#

  • Hebrew

  • BH English

  • WEB Match?

  • Notes/Next Action

  • 7225

  • ראשית

  • beginning

  • ✔ found

  • auto-accept

  • 430

  • אלהים

  • God

  • ✘ not found

  • manual or rule-based update

• Phase 3 — Auto-Map Pass Group

  • If BH token exists in the WEB verse:
    → Accept as public-domain-compatible word
    → Mark as PASS/AUTO-ASSIGN

  • This likely covers 70–90% of cases.

  • Data decides.

• Phase 4 — Failure Set (the gold mine)

  • These rows are where translations diverge.

  • For mismatched tokens:

  • You suggested (correctly):

  • Strategy:

  • Resolve at Strong's-level, not verse-level.

  • For each Strong's failing token, prepare approved English token set, e.g.:

  • Strong

  • Possible Tokens

  • H7307 (ruach)

  • spirit / breath / wind / mind / divine-breath etc

  • Then rule logic:

  • If WEB verse contains one of these tokens → auto-assign

  • Else → flag for manual researcher/gpt review

  • This shrinks human review load.

• Phase 5 — Normalization

  • To align datasets cleanly:

  • Add OSIS_ID + token index to BH

  • Ensure BH rows map 1-to-1 to OSHB structure

  • Strip BH odd rows (q/k) or map them systematically

  • After normalization:

  • 1C becomes programmatically buildable.

  • What makes this elegant:

  • ✔ Uses BH dataset work you already built
    ✔ Uses public domain text → safe for distribution
    ✔ Automates bulk and isolates outliers
    ✔ Data-driven, measurable, trackable, defensible
    ✔ Creates empirical visibility into translation drift
    ✔ Turns 1C into engineering, not guesswork

• In one sentence:

• You just designed an automated pipeline where modern English tokens are validated against a public domain text, accepting matches and routing mismatches into a review system — reducing manual work and establishing defensible provenance.

 

 

DB2 — Lexical Mapping  - Aggregate existing English definitions of Hebrew Words

Goal: Provide a stable bridge from OSHB lemmas to external lexicons (Strong’s, BDB, etc).

Input:

• DB1 lemma list (distinct lemmas)

• Public domain lexicons (Strong’s, BDB, others)

Output:​

• A lemma-index table: one row per lemma with:

• lemma_id

• OSHB lemma

• mapped Strong’s number(s)

• links to BDB/other ID

Function: This is a join table — not “meaning”. It lets you pull any dictionary view into any lemma or token.

• This is your connector. Not truth — just wiring.

​

•  

  ​my notes:

  NEED: researcher wanted to look at comparative definitions of Hebrew words

  • SUSPECT: the English definitions of some Hebrew words drift between sources.

  • Takes Strong’s Hebrew words and aggregates 3 public domain definitions

  • Maps DB1 lemmas (dictionary words) to lexical (dictionary) systems (Strong’s, BDB, modern lexicons).

  • This is a mirror of public domain definitions – no analysis or interpretation or changing of definitions – just mapping

• Goal: build the lookup framework for meaning reconstruction.

 

 

DB3 — Morphological Deconstruction – break down of Hebrew words into smallest parts (vowels, consonants, word prefix and suffix)

• NEED: identify root Hebrew words and bring back to pictograph letters

• SUSPECT: I think the words when looked at in pictographic letters can be understood not “read”.

• Separates vowels, prefix and suffix – no in original Hebrew but added later

• Bring words back to pictographic form – I think how the words were originally written

  • Hebrew letters were no just phonographic (produce a sound) they also had meaning

  • Hebrew was not “learned” as a language, the alphabet was taught and words were formed based on picture in mind from letters

  • Hebrew was understood and not read

  • THIS IS MY THEORY – I WILL PROVE OR DISPROVE AT THIS POINT

  • For example: A is aleph which was represented with an Ox head. The Ox head represented the attributes of aleph which is strength/strong, leader, power. English is much different, our letters have phonographic meaning only and even that is not at all consistently applied (silent letters, magic e, “sight words” which do not follow any spelling patterns), Hebrew was not this way.

• Bring words into “root” and “branch” form – making DB4 possible

 

 

DB4 — Root / Branch System – Identify Hebrew Word Families

• SUSPECT:  Hebrew words have 3 letter root letters and those that branch from that root also contain those 3 letters (I THINK)… I will use the root letters to identify the branches to link the words into families.

• Assign new numbering system (like Strong’s) except now connecting root to branches so word families are identifiable – this allows for meanings to be properly evaluated

  • Once the words are properly segmented root with branches, I can start to evaluate meaning.

• DB4 becomes the backbone of restored semantic (word meaning) analysis.

• NOTES:

  • Hebrew words are layered in depth and meaning but do not deviate logically, a word to describe cat would not be used to describe a light, they have no relationship.

  • Hebrew words follow this pattern (I THINK):

    • Concrete – what physically is

    • Functional – what it does

    • Extensions – analogies the word carries into other domains

    • Identity – how it reveals who or what someone is

    • Covenant – how it functions in YHWH’s legal order

      • Concrete – functional – extensions – identity – covenant – concrete

      • Face – presence – countenance – authority – covenant standing

      • Name – identity – reputation – authority/renown – covenant marker

 

 

DB5 — Comparative Gloss Network – Compare the Definitions

• SUSPECT: once we group the words and bring in the definitions, the real drift in Hebrew word meaning will become visible.

• Creates a structured, hierarchical meaning-map grounded in usage, not tradition.

• Comparing the definitions allows me to see many things:

  • Drift in English definitions in comparative sources

  • Drift within definitions within a source

  • Insertions of non-Hebrew ideas into Hebrew definitions, below are examples:

    • Cosmology: World, earth, heaven

    • Dualism: Soul, spirit, heaven, hell

    • Christian insertions: satan as a being 

• Quantifies usage patterns across time and context.

  • Forms the engine for later semantic weighting.

  • Uses cross-corpus patterns (translations, lexicons, cognates) to see how meaning drifted. Plainer: allows to see how words drifted between dictionaries and within the text itself.

  • Provides evidence for what changed, when, and how.

 

 

DB6 — Restored Meaning Extraction – Restored Meaning Hebrew Dictionary

• SUSPECT: What I think happened is when the translators could not find their worldview or their doctrine in the Hebrew language, the altered the meaning of the Hebrew words to fit their worldview.  For example:

  • Heliocentric worldview (planets and solar system) when Hebrews understood our world – center, flat, non-moving, sun/moon/stars rotate above us (not us moving)

  • Christian overlays: dualism like spirit and souls, the “devil” or Satan, eternity

  • Misunderstandings bc meaning is concrete not abstract, such as:

    • worship as an inward process, Hebrew means to bow down (physical)

    • serve as intentional, Hebrew means how you order your life

    • prayer as a way to “talk to YHWH” but Hebrew meant to cry out

• The idea is to restore the Hebrew understanding of the word based on the pictograph letters and carry the logical meaning from root to branch words

• This layer ensures definitions are logical (root to branch makes sense) and creates CONSISTENCY in usage coherence.

• This is the hardest part bc it will take everything I’ve learned and try to understand the Hebrew meaning and create definitions for Hebrew word families (root and branch)

• Hebrew is supposed to be intuitive, you learn the meanings for Hebrew letters which all have meaning and the words are a combination of the letters’ meanings

  • For each lemma, reconstructs its likely original conceptual value using DB1–DB5.

• Outputs the restored meaning table.

 

 

DB7 — Reprojection Into Text

• D7 is DB1 PLUS:

  • New numbering system that ties root to branch

  • Restored Hebrew meaning of the word

  • Pictograph root and branch word

• Applies restored meanings back into verse-level context (using simple vlookup mapping Strong’s to New ID system, and restored Hebrew definition)

• Generates consistent English tokens that reflect Hebrew worldview, not theological drift.

• Produces the final side-by-side comparison: traditional vs. restored Hebrew meaning.

• This would be in excel form, and because Hebrew is structurally different then English, the verses would need to be rewritten