Skip to content
OpenBody OpenBody™

Measurement-type registry

The measurement-type registry is the interop anchor for Measurement.type (§4.1, §4.5) and for the canonical channel-naming convention on a location Measurement’s sampleArray. Like the exercise registry, it is a separate, independently-versioned, fetchable artifact, decoupled from the spec — the spec defines the mechanism (source-native namespacing with lazy semantic resolution, §4.4); the registry ships content on its own cadence. The data is CC0. It lives in the openbody-registry repository, under vocab/measurements/.

A separate registry from the exercise registry

Measurement types are Pillar A — Observation/telemetry (heart rate, sleep, body composition, activity, power); the exercise registry is Pillar B — Structured Training (movement ids and their facets). Different domains, no subject-matter overlap, and — as below — a different, flatter model. Both are CC0 registry content decoupled from the core openbody spec repo, so they ship together from openbody-registry as two independently-evolving registries.

Flat controlled vocabularies, not combinatorial entries

Unlike the exercise registry, this registry has no canonical-entry-with-facets model and no crosswalk — measurement types are flat categorical tokens, not combinatorial movements. Each vocabulary is a controlled-vocabulary file in the open-token-set shape already used elsewhere in the spec for open, registry-backed fields (§5.9).

FileCovers
cardiovascular.jsonMeasurement.type — heart rate, resting HR, HRV, VO2max
respiratory.jsonMeasurement.type — respiratory subset
sleep.jsonMeasurement.type — sleep subset (§4.3)
body-composition.jsonMeasurement.type — body mass, body-fat %, etc.
activity.jsonMeasurement.type — activity/energy subset
power-pace.jsonMeasurement.type — power/pace subset
location-channel.jsonMeasurement.sampleArray.channels[].name for type: "location" — lat/lon/alt/speed/course

See the registry’s top-level vocab/index.json for the authoritative manifest.

Entry model

{
  "token": "heart_rate_variability",
  "label": "Heart Rate Variability",
  "aliases": ["hrv"],
  "description": "Most commonly RMSSD; producers SHOULD note the method (RMSSD/SDNN/etc.) in provenance or notes if not RMSSD. Recommended unit: ms."
}

A token’s recommended UCUM unit is noted in its description as a hint only — the record’s own unit field is authoritative (§4.1), not this file.

Scope (v1)

A narrow, hand-curated high-frequency wedge — the measurement types every mainstream health/fitness platform already exposes (Apple Health, Garmin, Google Health Connect, Whoop, Oura, Strava) — not an exhaustive clinical taxonomy.

How to contribute

  1. Decide which vocabulary file the token belongs in (or whether a new domain file is warranted).
  2. Add { token, label, description } (plus aliases if useful); note the recommended UCUM unit in the description.
  3. Validate: npm run check (schema conformance + token format/uniqueness within a file + cross-file token uniqueness). Green is required.

Licensing

Registry data is CC0 — the interop registry must be completely unencumbered.