Smart Data Models’ Candidates repository now includes two more ETSI SAREF extensions, both from the health and personal-devices space: saref4ehaw and saref4wear, together
contributing 41 candidate models. Both ship the full Candidates artifact set — a JSON Schema, an NGSI-LD @context, and all four example serializations — validated against its own schema.
SAREF4EHAW — 21 models
SAREF4EHAW (ETSI TS 103 410-8) is SAREF’s extension for eHealth and “ageing well” / active assisted living — the vocabulary behind remote health monitoring setups like a patient wearing a Body Area Network (BAN) of sensors, actuators, and wearables that funnel vital signs through a BAN hub to caregivers.
| Category | Models |
|---|---|
| Actors | HealthActor, Caregiver, Helper, User, Patient, ResponsibleParty |
| Activity | Activity, DailyActivity, NocturnalActivity |
| Body Area Network | Ban, BanApplicationTask, BanHub |
| Devices | HealthDevice, HealthActuator, HealthSensor, HealthWearable, FunctionalDevice |
| Communication | CommunicationInterface, CommunicationNetwork, CommunicationProtocol |
| Observation | ObservationCollectionExecution |
A good chunk of this extension is pure specialization with no new properties of its own — DailyActivity, HealthSensor, HealthActuator, HealthWearable, BanHub, Patient, and ResponsibleParty all inherit everything from a richer parent class, and each candidate’s description explains exactly what it inherits rather than inventing properties that don’t exist in the ontology.
https://github.com/smart-data-models/Candidates/tree/master/standards/saref4ehaw
SAREF4WEAR — 20 models
SAREF4WEAR (ETSI TS 103 410-9) covers wearable technology more broadly — smartwatches, fitness bands, implantable health monitors, smart textiles, even crowd-control badges used by event staff. Devices are classified by how they relate to the body (in-body, on-body, near-body, textile/fabric-integrated), linked to the “Wearer” they’re attached to, and described by the functions they perform (communicating, controlling, navigating, notifying) and the hardware components they’re built from.
| Category | Models |
|---|---|
| Wearable-device family | WearableDevice, InBodyWearable, OnBodyWearable, NearBodyWearable, TextileBasedWearable, FabricWearable |
| Actors / features of interest | Wearer, User, LivingOrganism, Software |
| Hardware components | Interface, PowerSupply, MemoryStorage, TextileBasedSensor |
| Functions | CommunicatingFunction, ControllingFunction, NavigatingFunction, NotifyingFunction |
| Governance & events | Policy, Occurrence |
The example data (a Garmin-style heart-rate monitor on a runner, an implanted glucose-style monitor, a crowd-control wearable detecting a restroom queue at a music festival) is drawn directly from the worked scenarios in the normative ETSI specification.
https://github.com/smart-data-models/Candidates/tree/master/standards/saref4wear
Translation notes
- Property-grouping classes flattened into plain attributes. Both ontologies classify measurable quantities (heart rate, battery level, air quality, soil moisture-style readings) using abstract grouping classes with no properties of their own, populated only by a handful of named individuals. Rather than mirroring that grouping hierarchy as
thin extra entities, each named individual became a directly-named attribute on the device/wearer that carries it (e.g.WearableDevice.batteryRemainingTime,Wearer.heartRate) — the ontologies’ own documentation explicitly endorses this as an open, non-exhaustive vocabulary rather than a closed enumeration. - TTL vs. normative-PDF discrepancies, documented rather than silently resolved. SAREF4EHAW’s PDF tables several properties (
hasHabit,hasInterface,availableFlash…) with explicit domains that aren’t actually declared in the published.ttl; SAREF4WEAR has a comparable gap (wearerRangeAgein the PDF vs.wearerAgeRangein the.ttl). Every such gap is flagged plainly in the affected property’s
schema description and instandard-metadata.yaml, with the.ttl
treated as authoritative. - One real naming collision found. Smart Data Models’ own
dataModel.Hl7already publishes aPatientmodel (the full FHIR resource). SAREF4EHAW’sPatientis a much narrower concept — a thin, zero-own-property “cared-for person” — kept under its own name per the translation policy, with the collision flagged for reconciliation before promotion out of Candidates. - Privacy-conscious examples. Given the personal-health subject matter, every SAREF4EHAW example uses clearly synthetic, non-identifying placeholder data.
Try it, and tell us what’s missing
These are Candidates — first, carefully-sourced translations, not yet promoted to official Smart Data Models subjects. The Patient naming collision above is the main open item before promotion.
Browse the models, open an issue, or send a PR:
👉 https://github.com/smart-data-models/Candidates/tree/master/standards/saref4ehaw
👉 https://github.com/smart-data-models/Candidates/tree/master/standards/saref4wear

