Skip to content

Widen schema:inDefinedTermSet and variableMeasured @type - #16

Merged
smrgeoinfo merged 2 commits into
mainfrom
widen-definedterm-variablemeasured
Aug 21, 2026
Merged

Widen schema:inDefinedTermSet and variableMeasured @type#16
smrgeoinfo merged 2 commits into
mainfrom
widen-definedterm-variablemeasured

Conversation

@smrgeoinfo

Copy link
Copy Markdown
Contributor

Two schema.org property definitions were narrower than their documented intent, leaving real cases with no valid spelling. Both were found through downstream use in the ADA geochemistry building blocks.

1. definedTermschema:inDefinedTermSet

-    type: string
+    anyOf:
+      - type: string
+      - type: object
+        required: ['@id']
+        properties: {'@id': {type: string}}

The class's own union-type policy, stated in its description, already says a DefinedTerm may be a plain string or a full object — but the vocabulary pointer inside it admitted only a string, so {"@id": "…"}, the natural JSON-LD spelling of a reference, was invalid. Both forms are already in use across CDIF profiles and downstream.

2. variableMeasured@type

     contains:
-      const: schema:PropertyValue
+      anyOf:
+        - const: schema:PropertyValue
+        - const: schema:PropertyValueSpecification

A variableMeasured item is either a measured value or a specification of one — the permitted range, default or unit rather than an observed result. Protocol and method descriptions declare the latter: an ADA TAPP states what a procedure will report before any measurement exists. Pinning @type to PropertyValue alone left that case unspellable.

For reviewers: cdifInstanceVariable separately requires cdi:InstanceVariable in the same array, and that is unchanged. The effective rule for a CDIF instance variable is still "cdi:InstanceVariable AND one of the two schema.org types" — this only widens which schema.org type satisfies the second half. Additional type URIs remain permitted.

Verification

Example validation 134 passed, 8 failed of 142
Same run with changes stashed 134 passed, 8 failed — identical
resolve_schema.py --all 92 schemas, 56 updated, 36 current
Resolver output no temp-dir $comment stamps, no dangling fragments

Widening these rejects nothing that previously validated — the before/after was measured by stashing, not assumed.

Why the resolved schemas are in this PR

The 56 regenerated resolvedSchema.json files are tracked artifacts, and downstream consumers read the resolved form rather than the source. Committing the source edits alone would leave 61 resolved copies asserting a constraint the source no longer has.

Note that downstream repos fetch these over HTTP from published gh-pages, so the change only reaches them once gh-pages republishes.

🤖 Generated with Claude Code

smrgeoinfo and others added 2 commits August 20, 2026 17:16
…for a real case

Both changes remove a constraint that was narrower than the documented intent,
and both were found by downstream use in the ADA geochemistry building blocks.

definedTerm: schema:inDefinedTermSet
  Was `type: string`. Now string OR an object reference ({"@id": "<uri>"}).

  The class's own union-type policy, stated in its description, already says a
  DefinedTerm may be a plain string or a full object - but the vocabulary POINTER
  inside it admitted only a string, so the object form, which is the natural
  JSON-LD spelling of a reference, was invalid. Both forms are already in use
  across CDIF profiles and in ADA building blocks downstream.

variableMeasured: @type
  Was `contains: {const: schema:PropertyValue}`. Now contains either
  schema:PropertyValue or schema:PropertyValueSpecification.

  A variableMeasured item is either a measured VALUE or a SPECIFICATION of one -
  the permitted range, default or unit rather than an observed result. Protocol
  and method descriptions declare the latter: an ADA TAPP states what a procedure
  WILL report before any measurement exists. Pinning @type to PropertyValue alone
  left that case no valid spelling. Additional type URIs remain permitted, so
  cdi:InstanceVariable continues to sit alongside.

Note for reviewers: cdifInstanceVariable separately requires cdi:InstanceVariable
in the same array, and that is unchanged. The effective rule for a CDIF instance
variable is therefore still "cdi:InstanceVariable AND one of the two schema.org
types" - this commit only widens which schema.org type satisfies the second half.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
resolve_schema.py --all: 92 schemas, 56 updated, 36 already current.

These are tracked artifacts, so the source edit and the regeneration have to
travel together - committing the first without the second would leave 61 resolved
copies asserting a constraint the source no longer has, and downstream consumers
read the resolved form, not the source.

Verified: no temp-dir $comment stamps and no dangling fragments in the output.
Example validation is 134 passed / 8 failed of 142, identical to the same run
with the source changes stashed, so widening these two definitions rejects
nothing that previously validated.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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