SAREF4CITY & SAREF4INMA Join Smart Data Models: 35 Candidate Models for Smart Cities and Manufacturing

Smart Data Models’ Candidates repository now includes two more ETSI SAREF extensions: saref4city and saref4inma, together contributing 35 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.

SAREF4CITY — 14 models

SAREF4CITY (ETSI TS 103 410-4, Oct 2024) is aimed at city administrations and smart-city platform builders who need a common, IoT-friendly vocabulary instead of yet another bespoke city data schema. It handles the “one KPI, many measurements” problem distinctly well: a general KPI definition (e.g. “road congestion”) is kept separate from its individual timestamped  ssessments, so historical values accumulate cleanly under one stable definition. It also gives city topology (countries → cities → districts → neighbourhoods, spatially linked via GeoSPARQL) a reusable shape, and models public services with who provides them, who uses them, where, and in what languages — directly reusing the EU’s own ISA² Core Public Service Vocabulary rather than reinventing it.

https://github.com/smart-data-models/Candidates/tree/master/standards/saref4city

SAREF4INMA — 21 models

SAREF4INMA (ETSI TS 103 410-5) targets factory operators, equipment vendors, and supply-chain software vendors who need to trace a manufactured item back to the exact production equipment, batch, raw material, and timestamp that produced it — both inside the factory and after the item has shipped. It gives semantic interoperability between heterogeneous  roduction-equipment vendors and a standard vocabulary for item/batch/material traceability, aligned with Industry 4.0 reference architectures and IEC 62264’s factory/site/area/work-center location model.

All 21 examples are drawn from, and cross-consistent with, the single worked “shaver manufacturing” scenario in the ETSI spec’s own clause 4.3 — so a reader can trace one shaver’s full genealogy across every model.

https://github.com/smart-data-models/Candidates/tree/master/standards/saref4inma

Translation notes

• Inheritance flattened, not duplicated. SAREF4CITY’s four AdministrativeArea subclasses (City, Country, District, Neighbourhood) and SAREF4INMA’s identifier subclasses (GTIN8ID…UUID → ID, WorkCenter → ProductionEquipment) inherit everything and add nothing of their own — each still gets its own candidate model, documenting what it inherits in its description rather than repeating properties, following the precedent set by this repo’s Gaia-X candidate.
• A documentation/ontology discrepancy, resolved transparently. ETSI TS 103 410-4’s own property table omits refersToFeature from KeyPerformanceIndicatorAssessment, but the published .ttl and the spec’s own figures both include it — the .ttl was treated as authoritative and the property included, with the discrepancy noted in standard-metadata.yaml.
• Six near-duplicate identifier relationships simplified. SAREF4INMA’s hasGTIN8ID/hasGTIN12ID/…/hasUUID convenience sub-properties were consolidated into one generic hasIdentifier relationship, documented as a simplification.
• License recorded exactly as found, not guessed — SAREF4INMA’sdct:license points to ETSI’s own forge software license.

Try it, and tell us what’s missing

These are Candidates — first, carefully-sourced translations, not yet promoted to official Smart Data Models subjects. Overlap with existing official subjects hasn’t been checked in detail, and license terms for the specific v2.1.1 releases should be confirmed before promotion.

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