Skip to content

Re-pin the vendored cdifTabularData: the counts now carry a propertyID - #55

Merged
smrgeoinfo merged 1 commit into
mainfrom
repin-cdiftabulardata
Oct 7, 2026
Merged

smrgeoinfo merged 1 commit into
mainfrom
repin-cdiftabulardata

Conversation

@smrgeoinfo

Copy link
Copy Markdown
Member

Takes mBB 7052e52a0 (their #48) into vendor/remote/ and re-resolves.

countRows/countColumns were bare unprefixed integers on the tabular distribution — the only two unprefixed properties among twenty-one prefixed siblings in composed adaProduct. Upstream they are now schema:additionalProperty PropertyValue entries whose schema:propertyID names the concept each quantifies: DDI Discovery caseQuantity for rows, variableQuantity for columns.

The vendored diff is only that change

+15 −5 in vendor/remote/.../cdifDataType/cdifTabularData/schema.yaml, and nothing else. Eight other vendored files appear modified in git status with zero content diff — the usual CRLF stat churn. I mis-read that as nine real upstream changes before checking git diff --numstat; worth stating because the vendoring design exists precisely so an unannounced upstream change can't hide in a large diff.

The lock re-pins 49 remote schemas. Downstream: 82 resolvedSchema.json, +10490 −4100, and 0 bare countRows/countColumns declarations remain anywhere in _sources.

The census found a "loss" — and it isn't one

76 blocks each report -1 closed. Cause: two inline copies of the propertyID anyOf — one under prov:wasGeneratedBy, one in $defs/Instrument_AdditionalProperty — collapsed into a single shared $defs/propertyID_item, because the upstream change introduced that as a named $def and the resolver now promotes it once instead of inlining it twice.

Verified the closure survives:

$defs/propertyID_item:
   type=object   required=['@id']   additionalProperties=false
sites now $ref'ing it: 3
   .../prov:wasGeneratedBy/.../schema:propertyID/items      <- was inline
   $defs/Instrument_AdditionalProperty/...                  <- was inline
   $defs/CdifTabularData_AdditionalProperty/...             <- new

One definition serving three sites where two were duplicated — strictly better coverage, one fewer counted node.

This is the census working as intended. 638 examples pass either way, so nothing else in the pipeline would have raised it; the count made me look, and looking showed it benign. Worth recording as a standing characteristic: deduplicating an inline constraint into a shared $def registers as a loss, because the census counts definitions, not the sites reached through them.

Verification

validate_examples 638 passed, 0 failed
validate_counterexamples 13/13 still rejected
constraint_census 247 blocks, 1,355,952 → 1,357,968; baseline updated with --write in this commit

gBB uses these properties in 0 of its own examples, so no example needed rewriting here — the change is schema-only on this side. amds-ldeo/metadata still has two subject-key rows (939 records each) pointing at the old bare path, which is that session's follow-up.

🤖 Generated with Claude Code

Takes mBB 7052e52a0 (its PR #48) into vendor/remote/ and re-resolves.
countRows and countColumns were bare unprefixed integers on the tabular
distribution -- the only two unprefixed properties among twenty-one
prefixed siblings in the composed adaProduct -- and upstream they are now
schema:additionalProperty PropertyValue entries whose schema:propertyID
names the concept each quantifies, DDI DISCOVERY caseQuantity for rows and
variableQuantity for columns.

The vendored diff is exactly that one upstream change: +15 -5 in
vendor/remote/.../cdifDataType/cdifTabularData/schema.yaml and nothing
else. Eight other vendored files show as modified in `git status` and have
ZERO content diff -- the usual CRLF stat churn, and I mis-read it as nine
real upstream changes before checking `git diff --numstat`. The lock file
re-pins 49 remote schemas.

Downstream: 82 resolvedSchema.json files, +10490 -4100, and 0 bare
countRows/countColumns declarations remain anywhere in _sources.

The census found a loss and it is worth recording why it is not one.
76 blocks each report `-1 closed`. Cause: two INLINE copies of the
propertyID anyOf -- one under prov:wasGeneratedBy, one in
$defs/Instrument_AdditionalProperty -- collapsed into a single shared
$defs/propertyID_item, because the upstream change introduced that as a
NAMED $def and the resolver now promotes it once instead of inlining it
twice. The closure is intact on the shared def
(type=object, required=['@id'], additionalProperties=false) and THREE sites
now $ref it, the two former inline ones plus the new
CdifTabularData_AdditionalProperty. One definition serving three sites
where two were duplicated: strictly better coverage, one fewer counted
node.

That is the census behaving as designed. 638 examples pass either way, so
nothing else in the pipeline would have raised this; the count made me look
and the investigation showed it benign. Worth knowing as a standing
characteristic: deduplicating an inline constraint into a shared $def
registers as a loss, because the census counts definitions and not the
sites reached through them.

  validate_examples        638 passed, 0 failed
  validate_counterexamples 13/13 still rejected
  constraint_census        247 blocks, 1355952 -> 1357968; baseline updated
                           with --write in this commit

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@smrgeoinfo
smrgeoinfo merged commit 597e44e into main Oct 7, 2026
4 checks passed
@smrgeoinfo
smrgeoinfo deleted the repin-cdiftabulardata branch October 7, 2026 22:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant