cdifTabularData: give the row and column counts a propertyID

[smrgeoinfo]

countRows and countColumns were the only two properties on this class with no namespace and no description — bare type: integer among twenty-one prefixed siblings (cdi:headerRowCount, cdi:skipRows, cdi:tableDirection, cdif:hasPhysicalMapping, …). Nothing said what they meant or tied them to a vocabulary, and because the class is open, nothing would ever complain.

They become schema:additionalProperty PropertyValue entries carrying a schema:propertyID:

property	schema:propertyID
countRows	http://rdf-vocabulary.ddialliance.org/discovery#caseQuantity
countColumns	http://rdf-vocabulary.ddialliance.org/discovery#variableQuantity

DDI Discovery, not Codebook — and the IRIs are not the doc anchors

Confirmed with the originator. The terms are read from the vocabulary, which declares "The namespace for all terms in this ontology is: http://rdf-vocabulary.ddialliance.org/discovery#".

The IRIs first proposed were https://rdf-vocabulary.ddialliance.org/discovery.html#dfn-disco-casequantity — documentation anchors, with a different path (discovery.html vs discovery), a different fragment form, and https where DISCO declares http. Either form is a string that validates, so a doc anchor would have sat in schema:propertyID identifying a web page instead of a property, and nothing downstream would have surfaced it.

Semantics line up: both DISCO properties are datatype properties with domain DataFile and LogicalDataSet, and this class describes a tabular data file. variableQuantity is the count of variables (columns), caseQuantity the number of cases (rows).

Shape

Follows the house pattern from cdifProvActivity — items $ref a $defs entry that in turn $refs schemaorgProperties/additionalProperty — rather than restating the PropertyValue shape locally.

Not a breaking change

The class has no additionalProperties: false, so the old bare form still validated. The 30 occurrences across 12 example and negative-test files (in cdifTabularData, cdifComplete, DiscoveryDataDescription) were updated to demonstrate the convention, not to repair a failure.

On the large cdifManifest diff

cdifManifest/resolvedSchema.json changes by ~650 lines, and that is this change rather than unrelated drift: swapping two scalars for a $ref inlines the whole additionalProperty definition (PropertyValue, DefinedTerm, propertyID_item) into the resolved output.

Verified by regenerating against a clean HEAD with no source edit — "0 updated, 68 already current" — so nothing was stale beforehand. (I initially mis-called this as pre-existing drift from a 5-of-657 keyword count; the inlined lines simply don't contain the words I grepped for.)

Verification

validate_examples	130 passed, 0 failed
test_fail_cases	103 of 103 still fail for the reason they name
resolve_schema --all / regenerate_schema_json	re-run; artifacts committed and idempotent on a second pass

Downstream

geochemBuildingBlocks vendors this class and shows these two on the distribution in composed adaProduct. gBB uses them in 0 of its own examples, so the impact there is schema-only: after this merges and gh-pages redeploys, gBB needs resolve_schema.py --refresh-remote plus a regenerate (~6 min). amds-ldeo/metadata has two subject-key rows (939 records each) pointing at the old bare path that need re-pointing at the additionalProperty path.

🤖 Generated with Claude Code