Skip to content

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:

  1. The first pass indexes every labelled target in every part: sections, tables, figures, context groups, templates, bibliography and glossary entries.
  2. 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.

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.