# LibreBible Roadmap LibreBible is the public Bible and study-resource data project behind Libre Study, GracePress Bible Tooltip, and future ChristIT Bible tools. Working names: - Project/catalog name: LibreBible - Technical repository: `libre-bible-data` - App consumer: Libre Study - Public catalog home: ChristIT.com - Git host/source backup: `https://git.christit.com/libre-study/libre-bible-data` ## Guiding Shape Keep one canonical data repo for now. Do not split each Bible translation into its own repo until a resource becomes large, independently maintained, or operationally painful inside the shared repository. Use stable resource ids, manifests, package folders, and generated docs to give each Bible/resource its own identity without creating unnecessary repositories. Preferred structure: ```text sources/ kjv-eng-kjv2006.json future-resource.json resources/ notes/ commentaries/ maps/ lexicons/ packages/ json/ catalog.json kjv-eng-kjv2006/ catalog.json verses.jsonl strongs-links.jsonl docs/ resources/ resource-manifest.md ``` ## Phase 1: Catalog Metadata Foundation Goal: make every resource self-describing enough for humans, apps, and public catalog pages. Tasks: - Expand source manifests with fields for translation date, source tradition/text basis, publisher/creator, upstream maintainer, copyright holder, license details, jurisdiction notes, and citation text. - Add attachment metadata that can describe Strong's links, morphology, lemmas, study notes, cross-references, maps, commentaries, lexicons, dictionaries, timelines, and media. - Add `resource_type` values such as `translation`, `study_notes`, `commentary`, `map`, `lexicon`, `dictionary`, `cross_reference`, and `timeline`. - Add relationship fields so one resource can attach to a Bible translation, book, chapter, verse, verse range, word/token, Strong's number, lemma, topic, place, or timeline event. - Generate `RESOURCE_INDEX.md` from structured metadata. - Generate one human-readable Markdown detail page per resource under `docs/resources/`. Definition of done: - The public Gitea repo README clearly links to a generated resource index. - KJV has a complete enough human-facing detail page to answer: what is it, where did it come from, who produced it, what is its license, what features does it include, and what package files are available. ## Phase 2: LibreBible Public Catalog on ChristIT.com Goal: make ChristIT.com the useful public face of LibreBible. Tasks: - Choose a public path such as `https://christit.com/librebible/`. - Build a PHP or similarly simple dynamic overlay that reads committed catalog JSON from a local checkout, a synced artifact folder, or stable Gitea raw/release URLs. - Render a Bible/resource browser from `packages/json/catalog.json` and per-resource `catalog.json` files. - Display title, abbreviation, language, translation date, creator/publisher, source, license, redistribution status, jurisdiction notes, features, counts, checksums, package files, and last upstream check. - Provide stable download URLs for generated packages. - Link back to the Gitea repo, source manifest, upstream source page, and generated resource detail page. - Avoid scraping README prose. Structured JSON is the machine truth; Markdown is for human explanation. Definition of done: - A normal visitor can answer which Bibles are available and whether each has Strong's, notes, commentaries, maps, or other attachments. - Libre Study and GracePress Bible Tooltip can use the same catalog information for package discovery. ## Phase 3: More Bible Sources Goal: grow beyond KJV while keeping license discipline. Priority sources: - eBible.org freely redistributable translations. - unfoldingWord/Door43 resources where licenses permit redistribution. - Open English Bible. - World English Bible. - Other public-domain or permissively licensed translations. Tasks: - Add source manifests before adding generated text. - Record upstream license, redistribution, and attribution details before import. - Add importer support for additional formats as needed: USFM zip, OSIS, plain text, TSV/CSV, JSON, XML, image files, or geospatial data. - Normalize all imported translations into shared package shapes. - Keep questionable resources as source metadata only until redistribution is clear. Definition of done: - At least three redistributable translations appear in the catalog with generated packages and clear license/source metadata. ## Phase 4: Attachments and Study Resources Goal: make LibreBible useful as a study ecosystem, not just a text repository. Priority attachments: - Strong's/concordance links. - Morphology and lemma data. - Study notes tied to verses or sections. - Cross-references. - Lexicons and dictionaries tied to Strong's numbers and lemmas. - Commentaries tied to verse ranges or scriptural sections. - Maps tied to places, events, books, chapters, and passages. - Timelines tied to events and passages. Tasks: - Define attachment package schemas. - Add package examples for each attachment type before bulk import. - Add relationship indexes so apps can ask: what attaches to this verse, range, word, Strong's number, lemma, place, or topic? - Preserve source attribution per attachment, not just per translation. - Add generated docs and catalog display for attachments. Definition of done: - The catalog can show a Bible translation and list its available attachments. - The catalog can also show an attachment and list which translations/passages it applies to. ## Phase 5: App and Plugin Consumption Goal: make LibreBible packages directly useful to Libre Study and GracePress. Tasks: - Define stable package URLs and version/checksum metadata for apps. - Add SQLite-ready package output for Libre Study. - Add WordPress/plugin-ready package output for GracePress Bible Tooltip. - Teach Libre Study to import from the public catalog, not just a sibling local repo. - Teach GracePress Bible Tooltip to discover/download supported translations from the catalog. - Keep app/user data separate from public Bible resource data. Definition of done: - Libre Study can install/update a Bible package from the public catalog. - GracePress Bible Tooltip can consume the same resource metadata and package outputs. ## Phase 6: Study Modes and Canon Profiles Goal: let users study from a chosen tradition, canon, or research profile without hardcoding one Protestant/KJV-centered shape into the app. Study modes should be neutral resource bundles. A mode may define preferred translations, canon/book coverage, notes, commentaries, dictionaries, maps, timelines, and warnings about resource scope or licensing. Modes should not imply endorsement; they are study lenses. Possible study modes: - Protestant / evangelical / Baptist-oriented 66-book study. - Catholic study with deuterocanonical books and Catholic-approved translations/resources where redistribution permits. - Eastern Orthodox study modes where suitable translations and canon metadata are available. - Ethiopian Orthodox study with broader canon metadata and resource discovery. - Coptic Orthodox study mode where suitable canon/resource data is available. - Research modes for movements or sects such as Latter-day Saint, Jehovah's Witness, Branhamite, or other historically significant groups, with explicit source attribution and clear separation from standard Bible translations. Tasks: - Add a `canon_profile` or `study_mode` metadata shape that can group translations and attachments without duplicating resources. - Record canon/book lists per profile instead of assuming every Bible is 66 books. - Allow resources to declare whether they are translation-specific, canon-profile-specific, denomination-specific, or translation-agnostic. - Keep commentaries, dictionaries, maps, and general reference works translation-agnostic unless the source says otherwise. - Keep translation footnotes, translator notes, study notes, Strong's links, morphology, and embedded cross-references tied to the translation/package that produced them. - Add catalog fields so Libre Study can show available modes and explain what resources are included. - Treat sect/movement modes as research profiles with careful naming, source context, and no implicit doctrinal endorsement. Definition of done: - LibreBible can describe at least one 66-book Protestant profile and one broader-canon profile. - Libre Study can switch a session into a profile and show which translations/resources are active because of that profile. - Resource metadata clearly distinguishes translation-specific attachments from reusable reference resources. ## Phase 7: Updates, Releases, and Automation Goal: keep upstream scanning and package publishing repeatable. Tasks: - Add scheduled update checks for source manifests. - Produce a report when an upstream checksum changes. - Require human review before accepting changed upstream text or license metadata. - Generate package checksums and release notes from structured data. - Tag stable resource package releases in Gitea. - Publish public catalog updates only from pushed commits. Definition of done: - A resource update can be checked, reviewed, regenerated, committed, pushed, and published without manual file hunting. ## Phase 8: Public Site Polish Goal: make the public LibreBible catalog feel like a real product. Tasks: - Add filters by language, license, feature, source, testament/canon, and attachment type. - Add detail pages for translations and attachments. - Add copyable package URLs for app/plugin integration. - Add provenance and license panels that are clear to normal users. - Add download buttons for supported package formats. - Add "used by" links for Libre Study, GracePress Bible Tooltip, and future tools. Definition of done: - The ChristIT.com LibreBible section is useful without opening Gitea. ## Open Decisions - Whether the public path should be `christit.com/librebible/`, another ChristIT path, or a dedicated domain/subdomain later. - Whether large generated packages should remain committed directly, move to Gitea releases, or be mirrored to a static download path. - Whether to eventually split especially large or independently maintained translations/resources into separate repos. - Which public package format should become the preferred app install format: JSONL bundle, SQLite bundle, zip package, or another signed manifest format. - How much Gitea itself should be customized after the ChristIT.com catalog proves the model. - How to name and present denomination, tradition, canon, and sect/movement research profiles in a way that is useful, accurate, and not confused with endorsement.