libre-bible-data/ROADMAP.md

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:

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: 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 7: 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.