This repository has no registry/ folder. Every sibling registry that has reached that stage has one, holding human-readable markdown tables generated from data/, and CECDR should match. The complication is that the partitions worth having depend on data the seed does not yet carry.
The sibling convention
| repo |
registry/ |
rows |
partition |
| crmedr |
12 files, 01-january.md … 12-december.md |
~4,700 |
by month (~400 rows, 16–26 KB each) |
| crpdr |
pontiffs.md |
265 |
single file |
| coecdr |
councils.md |
21 |
single file |
| cdoctdr |
doctors.md |
38 |
single file |
The shared shape, from crmedr/registry/01-january.md and crpdr/registry/pontiffs.md:
# Title, then a prose paragraph giving the count of canonical IDs, the semantics of every column, the source, and the standing note that all IDs are drafts pending committee review, linking ../docs/schema-proposal.md.- A markdown table with the ID in backticks (
`mr:0101-basilius`, `rp:peter`) plus contextual columns, including a Country column carrying ISO 3166-1 alpha-2.
- Generated by a script —
scripts/generate_registry.py (coecdr), scripts/extract_registry.py (crmedr) — never hand-edited. coecdr also ships test_generate_registry.py.
- Linked from the README's "Repository contents" section.
Why CECDR can't just copy either shape
A single file is out of the question. 2,935 rows with the columns we'd want is roughly 250 KB. The largest file anywhere in the family is 26 KB. GitHub stops rendering markdown tables well before 250 KB.
And the natural partitions are mostly unavailable today:
| axis |
current state |
usable? |
| circumscription type |
type is null for 2,934 of 2,935 entries |
no — this is the blocker |
| church sui iuris |
latin for all 2,935 |
no — one file, no partition, until Eastern circumscriptions land |
| nation |
complete: 203 countries + int |
yes, but see below |
So the axis the seed can support today is the one that partitions worst: 204 values, of which 81 have exactly one row and 111 have fewer than five. Median 4 rows per file. circ:int-opus-dei would be a one-row file. Against that, BR has 274, IT 222, US 177, CN 143, IN 133.
That is the substance of this issue: the tables become genuinely useful once the rank/type pass lands, and premature per-nation fragmentation would be worse than waiting.
Proposed shape
Primary view — geographic, available now. One file per continent or region, with an ## section per nation inside it. Five to seven files, no single-row files, no dependency on type. Region assignment needs a decision of its own: UN M49, or the Annuario Pontificio's own continental ordering (which would be more defensible for this registry).
Secondary views — once type is populated. registry/by-type/apostolic-vicariates.md, military-ordinariates.md, territorial-abbacies.md, and so on, per the enumeration already planned in docs/schema-proposal.md.
Third axis — once Eastern circumscriptions are seeded. Per church sui iuris, which is currently a single-valued column and only becomes a partition when the registry stops being Latin-rite-only.
Tooling. scripts/generate_registry.py plus a test module, matching coecdr; registry/ added to the README's "Repository contents"; files regenerated from data/circumscriptions.json, never hand-edited.
Question the multi-view structure raises
CRMEDR, CRPDR, COECDR and CDOCTDR each have exactly one view of their data, so the question has never come up. If CECDR ships geographic and by-type and by-church views, every ID appears in three files.
Is one view canonical with the others as generated cross-indexes, or are they peers? It matters for what a reader is expected to cite, and for whether a per-type file carries the full column set or just IDs and names pointing back to the geographic view. Worth settling before the generator is written rather than after.
Dependencies
Blocked on the rank/type enrichment pass for the by-type view. The geographic view is unblocked and could ship first.
Note that #3, #4, #5 and #6 all change IDs. Because these files are generated, that churn is cheap — but it is a reason to land the generator rather than any hand-written table.
Related: #3, #4, #5, #6. docs/schema-proposal.md — the planned type enumeration and § "Seed and its limits".
This repository has no
registry/folder. Every sibling registry that has reached that stage has one, holding human-readable markdown tables generated fromdata/, and CECDR should match. The complication is that the partitions worth having depend on data the seed does not yet carry.The sibling convention
registry/01-january.md…12-december.mdpontiffs.mdcouncils.mddoctors.mdThe shared shape, from
crmedr/registry/01-january.mdandcrpdr/registry/pontiffs.md:# Title, then a prose paragraph giving the count of canonical IDs, the semantics of every column, the source, and the standing note that all IDs are drafts pending committee review, linking../docs/schema-proposal.md.`mr:0101-basilius`,`rp:peter`) plus contextual columns, including aCountrycolumn carrying ISO 3166-1 alpha-2.scripts/generate_registry.py(coecdr),scripts/extract_registry.py(crmedr) — never hand-edited. coecdr also shipstest_generate_registry.py.Why CECDR can't just copy either shape
A single file is out of the question. 2,935 rows with the columns we'd want is roughly 250 KB. The largest file anywhere in the family is 26 KB. GitHub stops rendering markdown tables well before 250 KB.
And the natural partitions are mostly unavailable today:
typeis null for 2,934 of 2,935 entrieslatinfor all 2,935intSo the axis the seed can support today is the one that partitions worst: 204 values, of which 81 have exactly one row and 111 have fewer than five. Median 4 rows per file.
circ:int-opus-deiwould be a one-row file. Against that,BRhas 274,IT222,US177,CN143,IN133.That is the substance of this issue: the tables become genuinely useful once the rank/type pass lands, and premature per-nation fragmentation would be worse than waiting.
Proposed shape
Primary view — geographic, available now. One file per continent or region, with an
##section per nation inside it. Five to seven files, no single-row files, no dependency ontype. Region assignment needs a decision of its own: UN M49, or the Annuario Pontificio's own continental ordering (which would be more defensible for this registry).Secondary views — once
typeis populated.registry/by-type/apostolic-vicariates.md,military-ordinariates.md,territorial-abbacies.md, and so on, per the enumeration already planned indocs/schema-proposal.md.Third axis — once Eastern circumscriptions are seeded. Per church sui iuris, which is currently a single-valued column and only becomes a partition when the registry stops being Latin-rite-only.
Tooling.
scripts/generate_registry.pyplus a test module, matching coecdr;registry/added to the README's "Repository contents"; files regenerated fromdata/circumscriptions.json, never hand-edited.Question the multi-view structure raises
CRMEDR, CRPDR, COECDR and CDOCTDR each have exactly one view of their data, so the question has never come up. If CECDR ships geographic and by-type and by-church views, every ID appears in three files.
Is one view canonical with the others as generated cross-indexes, or are they peers? It matters for what a reader is expected to cite, and for whether a per-type file carries the full column set or just IDs and names pointing back to the geographic view. Worth settling before the generator is written rather than after.
Dependencies
Blocked on the rank/type enrichment pass for the by-type view. The geographic view is unblocked and could ship first.
Note that #3, #4, #5 and #6 all change IDs. Because these files are generated, that churn is cheap — but it is a reason to land the generator rather than any hand-written table.
Related: #3, #4, #5, #6.
docs/schema-proposal.md— the plannedtypeenumeration and § "Seed and its limits".