SAREF4ENER & SAREF4ENVI Join Smart Data Models: 116 Candidate Models for Energy Flexibility and Environment

Smart Data Models’ Candidates repository now includes two new candidate standards translated from ETSI’s SAREF (“Smart Applications REFerence”) ontology family: saref4ener and saref4envi, together contributing 116 candidate models. Both are official ETSI Technical Specifications, each with a normative PDF and a published Turtle/JSON-LD/RDF-XML ontology, and both ship the full Candidates artifact set — a JSON Schema, an NGSI-LD @context, and all four example serializations (NGSI-v2 and NGSI-LD, key-values and normalized) — validated against its own schema.

SAREF4ENER — 61 models

SAREF4ENER (ETSI TS 103 410-1) is the SAREF extension for energy flexibility and demand-response: the vocabulary behind smart appliances, batteries, and loads that can shift or modulate their power consumption in response to grid signals or incentives. It covers seven distinct “flexibility profile” shapes (power-envelope, power-limit, fill-rate, incentive-table, demand-driven, operation-mode…), the request/offer/instruction messages exchanged between a flexibility provider and a grid operator, load-control events and states, and the generic data-point/time-series building blocks used throughout.

Branch: saref4ener-candidates — PR not yet opened.

SAREF4ENVI — 55 models

SAREF4ENVI (ETSI TS 103 410-2)
covers two distinct worlds under one ontology: a lighting/light-pollution domain (lampposts, light points, illuminance/sky-brightness observations) and a full waste-management lifecycle — from a resident’s bin, through collection rounds, to treatment, disposal, and the emissions and secondary resources that treatment produces.

A rich object-property graph (accepts, isProducedBy, isDepositedIn, becomes, followsItinerary…) is translated throughout as NGSI-LD Relationships between these models.

Branch: saref4envi-candidates — PR not yet opened.

Translation notes

• Open vocabularies stay open. Both ontologies lean heavily on abstract “Kind” classification classes (WasteKind, ContainerKind, EmissionKind…) whose members are a small, fixed vocabulary rather than independently-instantiable things. Rather than creating dozens of near-empty entity types, these were folded into open/enumerated string attributes on the entities that actually reference them (e.g. Container.acceptedWasteKinds, Emission.emissionKind).
• Names preserved verbatim. SAREF4ENVI’s own class and property names were already PascalCase/camelCase and needed zero renaming. SAREF4ENER’s profile/instruction naming (OMBCInstruction, FRBCInstruction, …) is kept exactly as the ontology defines it.
• Inheritance flattened, not duplicated. Following the precedent set by this repo’s Gaia-X candidate, a subclass’s schema lists only its own attributes; inherited ones are documented in its description instead of repeated (e.g. SAREF4ENVI’s House/NonResidentialBuilding point back to Building/Perimeter).
• License recorded exactly as found. Both ontologies’ dcterms:license resolves to ETSI’s own software license terms (BSD-3-Clause for SAREF4ENVI) — recorded in each standard’s standard-metadata.yaml for confirmation before promotion out of Candidates.

Try it, and tell us what’s missing

These are Candidates — first, carefully-sourced translations, not yet promoted to official Smart Data Models subjects. A few things are open and would benefit from community input before that step: license confirmation for the specific v2.1.1 releases, and a check for overlap with existing official subjects (dataModel.Device, dataModel.Environment,
dataModel.WasteManagement-adjacent models).

Browse the models, open an issue, or send a PR:
👉 https://github.com/smart-data-models/Candidates/tree/master/standards/saref4ener
👉 https://github.com/smart-data-models/Candidates/tree/master/standards/saref4envi