How a build works
A knowledge base goes through three steps: fetch downloads the source,
build turns it into a SQLite database, and queries read that database
offline.
fetch reads the edition label (such as 2026d) from NEMA’s current release
listing, then downloads each part’s DocBook XML. It writes a manifest with
each file’s URL, size and SHA-256 under artifacts/<edition>/. Downloads are
retried, and a short download is rejected before it replaces anything.
The edition label is fixed from that point on. A later NEMA release is fetched as a new edition beside the old one.
build parses every part twice:
- The first pass indexes every labelled target in every part: sections, tables, figures, context groups, templates, bibliography and glossary entries.
- The second pass renders each section and table as markdown against that
index, so a cross reference reads as its target (
See PS3.5 Section 7.5.2,BCID 7010) instead of disappearing.
From the same source, part-specific parsers record data elements and UIDs
(PS3.6), IODs, modules, macros and value lists (PS3.3), SOP Classes (PS3.4),
transfer syntaxes (PS3.5), and context groups, templates and codes (PS3.16).
A full-text index over every section and table backs dicom_search.
Each part’s parse and import runs as one step. A row or link the parser cannot use is logged as a gap and the build continues; see Coverage and limits. The build is staged next to the target and replaces the live database only when it completes.
Editions
Section titled “Editions”Each database holds one edition and is named after it:
db/<edition>.sqlite. Queries use the newest built edition unless you name
another with --edition, --db or configuration.
Every answer’s Source: line ends with the edition it came from.
A database records the schema version of the code that built it. When the code
changes its schema, queries refuse the old database and ask for
dicom-kb build --force, which rebuilds from the files already fetched.