Construction index renders categories alphabetically, not in the BARD glossary's order

[rybesh]

The construction index (/construction.html) renders its category sections in alphabetical order:

Enclosure · Genre/Form · Materials · Process/Technique · Structure/Physical Format

The Book Arts Research Database glossary we follow (docs/bard-glossary.pdf) sequences them differently, and that sequence is meaningful — it runs from what a book is made of through how it is made to what it ends up as:

Materials · Process/Technique · Hand Papermaking Traditions ·
Structure/Physical Format · Enclosure · Genre/Form

Our alphabetical rendering is an accident of ORDER BY ?categoryLabel in web/queries/construction-methods.rq:52, not a decision. It puts Enclosure first and buries Materials in the middle.

Why this isn't a one-line fix

The category label is the only thing the web query knows about a category, so there's nothing to sort on but its text. Fixing it means carrying an explicit rank from the place the categories are actually defined — the VALUES block in sources/construction/build-scheme.rq — through the graph and into the query.

Sketch:

1. Add an ordinal to the VALUES block alongside the slug and label:

   VALUES (?category ?catSlug ?catLabel ?catRank) {
     ("material"  "material"  "Materials"@en  1)
     ("process-technique" "process-technique" "Process/Technique"@en 2)
     ...
   }

2. Emit it on the category top concept, e.g. ab:categoryRank ?catRank (new property — would also want adding to docs/vocab.ttl, which is already noted as needing a normalization pass in CLAUDE.md).
3. web/queries/construction-methods.rq selects it and orders ?catRank LCASE(?label) instead of ?categoryLabel LCASE(?label).

The template needs no change — since #117 it opens a new section whenever ?categoryLabel changes, so it follows whatever order the query returns.

Notes

• sources/subjects/ has the same shape (a VALUES block of categories, an index grouped by label), so whatever we land here probably wants mirroring there.
• hand-papermaking-traditions currently has no rows, so it emits no top concept and won't appear until it does — the ordinal should still be reserved for it.
• Purely presentational; nothing about the concepts or their skos:broader links changes.

Context: came out of the review on #117, where the categories moved to the BARD vocabulary and the index sections became data-driven.

[rybesh]

Heads-up on where this issue's starting state comes from: the category list here describes the unmerged construction-decision-update branch, not main. Anyone picking this up cold from main will not reproduce the symptom.

What main actually renders

web/site/construction.html on main has four sections, and they are hard-coded as literal <h2> blocks in web/templates/construction-methods.html, each filtering the row set with {{ if eq .categoryLabel "…" }}:

Binding and format · Materials · Production and printing · Techniques

Those four are the whole VALUES block in sources/construction/build-scheme.rq:53-58 (180 concepts). There is no Enclosure, no Genre/Form, no Hand Papermaking Traditions — so the ordering complaint can't be reproduced against main, and ORDER BY ?categoryLabel in web/queries/construction-methods.rq:52 currently has no effect on section order at all, only on concepts within a section.

What the branch changes

origin/construction-decision-update (23 commits ahead; 5450ab61 "use the glossary's category headings verbatim") does two things that together produce exactly what this issue describes:

1. Replaces the four categories with the BARD six, labels verbatim from the glossary and listed in glossary order in the VALUES block. Five end up populated — hand-papermaking-traditions draws no concepts — for 231 concepts total:

   category	concepts
   structure-physical-format	70
   process-technique	60
   material	50
   genre-form	39
   enclosure	12

2. Rewrites the template to derive sections from the data rather than hard-coding them — a new <h2> opens whenever ?categoryLabel changes, on the stated assumption that "construction-methods.rq ORDERs BY ?categoryLabel, so rows arrive grouped."

Step 2 is the actual origin of this bug. Hard-coded headings carried their own order; the data-driven version inherits the query's sort, and that sort is alphabetical. The glossary order sitting in the VALUES block is not carried anywhere — the branch does not touch web/queries/construction-methods.rq, which is still ORDER BY ?categoryLabel LCASE(?label).

Consequences for the fix

• The sketch in the issue body (add an ordinal to the VALUES block, carry it through the graph into the query) is still the right shape, but it patches a VALUES block the branch has already rewritten. Land construction-decision-update first, then apply the ordinal on top — doing it in the other order guarantees a conflict in that block and leaves the ordinal attached to four categories that are about to be replaced.
• Until that branch merges, this issue is not reproducible on main, which is worth knowing before someone tries.
• The branch's genre-form category (39 concepts) overlaps [Single record] genre/form #25 ([Single record] genre/form): it puts genre/form headings on the book page under the construction heading, whereas [Single record] genre/form #25 asks for a bf:genreForm field of its own. See the analysis in [Single record] genre/form #25 — the two should be reconciled before either is built.