libre-study/libre-bible-data
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Phase 1 enrich KJV manifest metadata

Browse Source
This commit is contained in:
Jason
2026-07-11 21:52:17 -05:00
parent 5c45070dc6
commit 29bbc41b55
8 changed files with 272 additions and 24 deletions
Download Patch File Download Diff File Expand all files Collapse all files
CONVENTIONS.md
+18 -2
View File
@@ -21,6 +21,8 @@ The long-term goal is a dynamic resource library that applications can search, i
- Local development happens in the workspace repo on drive `W:`.
- The Christ Unscripted Gitea remote is the remote backup, collaboration, and publishing copy.
- Do not treat resource work as durable until it is committed locally and pushed to Gitea.
- Every named implementation phase should bump the repo version and be recorded in Git both locally and remotely.
- Phase completion means the version bump, code/data/docs changes, and validation result are committed locally and pushed to Gitea.
- The normal flow is local import/check, generated package verification, local commit, push to Gitea, then publish generated catalogs or releases from the pushed state.
- The local repo and the Gitea repo are both intentional copies. Either should be enough to recover the project if the other system fails.
- Do not publish generated resources or release artifacts from a dirty worktree unless Jason explicitly asks for that exact operation.
@@ -62,8 +64,11 @@ Every source resource needs a manifest in `sources/`.
Each manifest should record:
- Stable resource id.
- Resource type, such as `translation`, `study_notes`, `commentary`, `map`, `lexicon`, `dictionary`, `cross_reference`, or `timeline`.
- Human title and abbreviation.
- Language.
- Language code, language name, script, and dialect when relevant.
- Translation date, edition date, source text basis, tradition, and public description when the resource is a Bible translation.
- Contributors and maintainers with their roles.
- Upstream provider.
- Upstream human URL.
- Upstream download URL.
@@ -74,7 +79,18 @@ Each manifest should record:
- Last checked timestamp.
- Importer name and version.
- Generated package paths.
- Feature flags such as `strongs`, `notes`, `morphology`, `commentary`, `maps`, or `cross-references`.
- Structured features and attachment metadata such as `strongs`, `notes`, `morphology`, `commentary`, `maps`, or `cross-references`.
Bible translation manifests should be broad enough to describe editions that include more than plain verse text. A translation may include or later connect to Hebrew, Greek, or Aramaic concordance entries, morphology, lemma links, study notes, commentaries, maps, timelines, media, and cross-reference resources. Do not encode KJV-only assumptions into the manifest shape.
Attachment metadata should identify:
- Attachment resource type.
- Whether the attachment is embedded in the source package or external.
- Relationship type, such as `word-to-strongs`, `verse-to-note`, `range-to-commentary`, `place-to-map`, or `event-to-timeline`.
- Anchor types, such as translation, book, chapter, verse, verse range, word/token, Strong's number, lemma, topic, place, or timeline event.
- Languages and systems involved, such as Hebrew, Greek, Aramaic, Strong's, morphology, or source-language lemmas.
- Generated package path when the attachment is packaged.
## Metadata Truth