Author: maestro

State of the Candidates Repository: 29 Standards, 385 Data Models

  By

This is just a summary for the participants of the FIWARE global summit 2026. See you there in Menton.

Smart Data Models’ Candidates repository has grown a lot over the past few weeks. This post is a single roundup of everything in it today: 29 source standards, translated into 385 NGSI-LD / NGSI-v2 candidate data models, each shipping 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.

Every one of these is a Candidate: a first, carefully-sourced translation from a real external ontology or specification, not yet promoted to an official Smart Data Models subject. Several carry known open items — license reconciliation, overlap checks against existing official subjects, or cross-standard naming collisions — noted in each standard’s own standard-metadata.yaml and summarized below where relevant.

When real use of the candidates is found then it will be come official smart data models in the usual repositories. WE are trying to help adoption of open standards but only when the standards are actually used.

By the numbers
Source standards translated 29
Candidate data models 385
Largest single standard Gaia-X Ontology (165 models)
Standards from the EDINT data space 20
Domains touched Smart Cities, Transportation, Energy, Environment, Cloud/Data Spaces, Cross-Sector Manufacturing, Building

The full list

Smart cities & urban infrastructure (EDINT data space)

The bulk of recent growth comes from systematically translating the EDINT (Espacio de Datos para las Infraestructuras Urbanas Inteligentes) family of ontologies — 20 standards covering nearly every domain a Spanish local government manages.

Standard Models What it covers
edint-infraestructura 19 Municipal facilities, sensors, observations, violations, traffic incidents, control/measuring equipment, regulated zones
edint-alumbrado-publico 12 Public street lighting: posts, luminaires, lamps, control centers, energy consumption
edint-trafico 7 Standalone traffic ontology: street sections, incidents, control/measuring equipment, observations
edint-vehiculos-compartidos 7 Shared-mobility vehicles, stations, docks, routes and waypoints
edint-catastro 6 The Spanish Cadastre: parcels, properties, constructions, references, renovations
edint-aparcamiento 5 On-street and off-street parking, fees, spots, spot groupings
edint-censo-locales 5 Commercial premises census: spaces, entities, permits, terraces, aggregations
edint-fotovoltaica 5 Photovoltaic systems, meters, generation observations, contracts, rates
edint-suministro 5 Utility supply points, meters, consumption, contracts, rates
edint-gestion-residuos 4 Waste collection points (mobile & permanent), containers, management facilities
edint-medio-ambiente 3 Generic environmental sensor platforms, sensors and observations
edint-censo-vehiculos 2 Vehicle registry and access/parking permits
edint-promocion-comercial 2 Commercial promotion campaigns and events
edint-servicios-publicos 2 Public services and their administrative procedures (CPSV-AP)
edint-agenda 1 City events published in municipal public agendas
edint-contaminacion-acustica 1 Noise pollution observations
edint-oferta-inmobiliaria 1 Real estate listings (sale, rent, transfer)
edint-organizaciones 1 Spanish public administration organizations and org charts
edint-zona-regulatoria 1 Regulated zones (low-emission, parking, pedestrian, historical center, …)
edint-turismo 11 SEGITTUR’s Core Tourism Ontology: accommodation, historical/cultural resources

Cross-sector & building

Standard Models What it covers
cityjson-v2 33 All 33 CityJSON v2.0.2 City Object types: buildings, bridges, tunnels, transportation, vegetation, water, land use
brick-schema 10 Building automation/IoT metadata: points, equipment, and their relationships
gaiax-ontology-v2111 165 Gaia-X Trust Framework: cloud/infrastructure offerings, connectivity metrics, legal/compliance/credential vocabulary
untp-v0.8.0 2 UN Transparency Protocol Digital Product Passport and Product

Transportation

Standard Models What it covers
era-rinf 38 ERA Register of Infrastructure: EU rail network topology, tracks, signalling, electrification
era-evr 14 ERA European Vehicle Register: individual authorised rail vehicles
era-eradis 14 ERA document/certification register
era-eratv 8 ERA European Register of Authorised Vehicle Types
madrid-accidentes-trafico 1 Madrid City traffic accident records

A few things worth knowing before you build on these

  • License status varies. Most EDINT candidates are CC-BY-4.0 (matching Smart Data Models’ own convention); a handful of others (edint-infraestructura, edint-turismo, edint-zona-regulatoria) are CC-BY-SA-4.0 from their source and haven’t been reconciled yet. madrid-accidentes-trafico‘s license isn’t stated in its source at all. Check each standard’s licenseNote before using it beyond evaluation.
  • A few entity names collide across standards. Because several EDINT ontologies independently reference the same real-world concepts (a regulated zone, a vehicle, a parking facility, an organization, a cadastral property, a “permit”), more than one candidate defines an NGSI-LD type with the same name but a different property set. Each collision is documented in the relevant standard-metadata.yaml — most likely resolution is consolidating on the fuller, more authoritative definition once these move past Candidate status.
  • Every translation favors real, sourced data over invented examples wherever the original specification provided any — actual open datasets, published sample instances, or real government records, not synthetic placeholders, whenever available.

Browse, and tell us what’s missing

👉 smart-data-models/Candidates

Each standard’s directory under standards/ has its own standard-metadata.yaml with full translation notes, scope decisions, and known caveats. Open an issue or send a PR if you spot something worth fixing before promotion.

UNTP Digital Product Passport Joins Smart Data Models: Two new candidate models — DigitalProductPassport and Product

  By

Smart Data Models’ Candidates repository now includes a new candidate standard, untp-v0.8.0, translated from the UN Transparency Protocol (UNTP) Digital Product Passport specification — a B2B data standard, issued as a W3C Verifiable Credential, for carrying product and sustainability information through supply chains. Two entities are covered: DigitalProductPassport and Product.

What’s in it

Model What it is
DigitalProductPassport The W3C Verifiable Credential (VCDM 2.0) envelope: issuer, validity period, credential status, render method, issuing software.
Product The core product data model: identification, classification, material provenance, producing facility, dimensions, packaging, performance claims, and an open industry-specific characteristics extension point.

Every model ships the full set of Candidates artifacts: a JSON Schema, an NGSI-LD @context, and all four example serializations (NGSI-v2 and NGSI-LD, key-values and normalized) — each validated against its own schema.

Two entities, one relationship — not one flattened blob

In the source, DigitalProductPassport.json‘s credentialSubject is literally $ref: "#/$defs/Product" — a 1:1 inline embedding. But Product.json is also published standalone, with its own complete identity independent of any credential wrapper. This candidate keeps that distinction: DigitalProductPassport carries only the envelope fields plus a product Relationship, and Product is its own separately-addressable entity — avoiding a ~20-property duplication and matching how the source itself chose to publish two files, not one.

The VC envelope fields (issuer DID, credential status, render method, issuing software) are modeled faithfully as real typed properties rather than simplified away — even though they’re strictly artifacts of the credential-verification layer, not “product data” per se.

Real context, real examples — not invented

Two things set this translation apart from working off prose docs alone:

  • A genuine published JSON-LD context. UNTP ships a complete, ~106KB context file using JSON-LD type-scoped contexts. This candidate’s context.jsonld IRIs are extracted from that real file — with two scope-collision bugs caught and hand-corrected along the way (a naive flatten of a type-scoped context can silently grab a same-named term from an unrelated class; here it briefly mapped the envelope’s validFrom to an unrelated ConformityProfile field, and the new product Relationship to an unrelated Digital Traceability Event term, before being fixed).
  • Real sample data. Both example.json files are drawn from UNTP’s own published sample instance — a 75 kWh Li-ion EV battery pack passport, complete with real material provenance (cobalt from DRC, lithium from Chile, nickel from Indonesia, …) and EU Battery Regulation performance claims — not fabricated placeholder values.

One naming fix was needed: the source’s own @context property (the W3C VC context array) would collide with NGSI-LD’s reserved top-level @context mechanism, so it’s renamed to vcContext — the same pattern already used for a dataProvider collision in the Gaia-X candidate.

Note on scope

Per explicit instruction, only these two entities are covered. UNTP defines several other credential types this specification references — Digital Conformity Credential, Digital Facility Record, Digital Traceability Event, Digital Identity Anchor — none of which are modeled here. Fields that reference them (e.g. producedAtFacility, a claim’s evidence links) stay exactly as the source declares them, not promoted to Relationships pointing at not-yet-modeled entity types.

Try it, and tell us what’s missing

This is a Candidate — a first, carefully-sourced translation, not yet promoted to an official Smart Data Models subject. Before that step:

  • License terms haven’t been confirmed against the spec-untp repository’s own LICENSE file yet.
  • Overlap with other Smart Data Models product/traceability vocabularies hasn’t been checked in detail.

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

CityJSON/ciutyGML Joins Smart Data Models: 33 Candidate Models for 3D City Objects

  By

Smart Data Models’ Candidates repository now includes a new candidate standard, cityjson-v2, translated from CityJSON v2.0.2 — a JSON encoding of a subset of the OGC CityGML data model for 3D city models. All 33 core City Object types defined in cityjson/specs‘ schemas/cityobjects.schema.json now have an NGSI-LD / NGSI-v2 representation.

What’s in it

Family Models Examples
Building 8 Building, BuildingPart, BuildingUnit, BuildingStorey, BuildingRoom
Bridge 6 Bridge, BridgePart, BridgeInstallation, BridgeConstructiveElement
Tunnel 6 Tunnel, TunnelPart, TunnelHollowSpace, TunnelInstallation
Transportation 4 Road, Railway, TransportSquare, Waterway
Generic / furniture 3 GenericCityObject, OtherConstruction, CityFurniture
Vegetation 2 PlantCover, SolitaryVegetationObject
Water, terrain, land use, grouping 4 WaterBody, TINRelief, LandUse, CityObjectGroup

Every model ships the full set of Candidates artifacts: a JSON Schema, an NGSI-LD @context, and all four example serializations (NGSI-v2 and NGSI-LD, key-values and normalized) — each validated against its own schema.

Built from real JSON Schema, mechanically — attributes included

Unlike some other Candidates translations that had to work from prose documentation pages, CityJSON ships genuine machine-readable JSON Schema files (schemas/cityjson.schema.json, cityobjects.schema.json, geomprimitives.schema.json, …). This translation parsed those directly, which surfaced a structural fact worth calling out: CityJSON’s own schema deliberately leaves attributes open on every City Object type ({"type": "object"}, no fixed sub-schema) — it defers attribute content to convention rather than declaring it.

That convention is CityGML’s own data model, so this candidate goes one step further and cross-references the actual OGC CityGML 3.0 XML Schema to promote real, typed, documented properties in place of the open bag: coded classification fields (class, function, usage, roofType), storey counts and heights, a qualified height structure (CityGML 3.0’s structured replacement for the classic flat measuredHeight), vegetation attributes (species, trunkDiameter, crownDiameter, …), and three real closed enumerations resolved directly from the XSD (conditionOfConstruction, height[].status, trafficDirection). Every model keeps a residual genericAttributes property too — but that maps to CityGML’s own formal generic-attribute extension mechanism, not an invented catch-all.

Three modeling decisions were made deliberately, not incidentally:

  • Geometry is flattened per Level of Detail. CityJSON stores vertices once in a document-level shared array and each Geometry entry references them by index, with an independent LoD per entry (a City Object can carry several simultaneously). Each model exposes up to four GeoProperties — geometryLoD0 through geometryLoD3 — holding real, dereferenced GeoJSON coordinates for whichever LoD the source data provides. Solid/MultiSolid primitives (CityJSON’s 3D volumes) are simplified to GeoJSON MultiPolygon, since GeoJSON has no native 3D solid type; surface semantics, material, and texture metadata is not carried into the GeoProperty.
  • No invented RDF vocabulary. CityJSON, unlike an OWL ontology, doesn’t publish per-property IRIs. Structural context.jsonld entries (geometry, parents/children, …) mint IRIs under CityJSON’s own schema $id namespace; the newly-promoted typed attributes mint IRIs under each model’s real CityGML 3.0 module XML namespace instead — both documented as conventions, not presented as something either spec formally declares at that exact granularity.
  • Coded values stay open. gml:CodeType attributes (class, function, usage, roofType, species) are typically drawn from OGC-published code lists; those lists weren’t resolved to closed enums in this pass, so these remain open strings with a note — a documented follow-up, not a silent gap.

Note on scope

This candidate covers CityJSON, which is explicitly documented as “a subset of the OGC CityGML data model” — not the full CityGML standard (a separate XML/GML/UML specification with its own ADE extension mechanism and modules CityJSON doesn’t carry). If full CityGML fidelity is needed, that’s a distinct, larger translation task from a different source spec.

Try it, and tell us what’s missing

This is a Candidate — a first, carefully-sourced translation, not yet promoted to an official Smart Data Models subject. Before that step:

  • Overlap with existing Smart Data Models building-related subjects hasn’t been checked in detail.
  • License terms (CC0-1.0 per the specs repo’s own LICENSE file) should be reconfirmed for the specific release before promotion.
  • CityGML’s own code lists (schemas.opengis.net/citygml/codelists/) aren’t cross-referenced yet — resolving them would turn the remaining open class/function/usage/roofType/species strings into real closed enums, the same way conditionOfConstruction/trafficDirection already are.

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

 

Gaia-X Ontology Joins Smart Data Models: 165 Candidate Models for Cloud, Connectivity & Trust

  By

Smart Data Models’ Candidates repository now includes a new candidate standard, gaiax-ontology-v2111, translated from the Gaia-X ontology v2111 — the vocabulary behind Self-Descriptions in Gaia-X federated data spaces and cloud ecosystems. All 165 classes published at docs.gaia-x.eu/ontology/v2111/classes now have an NGSI-LD / NGSI-v2 representation.

What’s in it

Gaia-X’s ontology is broader than a typical device/observation vocabulary — it describes both the physical/technical side of an offering and the legal/governance claims attached to it. That split shows up directly in the model mix:

Category Models Examples
Legal & governance documents 50 LegalDocument, TermsAndConditions, DataUsageAgreement, ServiceAgreementOffer
Compute & software 27 CPU, GPU, Memory, Hypervisor, ComputeFunctionRuntime, Image
Security 25 Encryption, PhysicalSecurity, InformationSecurityPolicies, ProductSecurity
Network 23 Endpoint, VLANConfiguration, InterconnectionServiceOffering, PointOfPresence
Infrastructure 19 Datacenter, AvailabilityZone, Region, PhysicalResource
Service offerings 17 ServiceOffering, ComputeServiceOffering, StorageServiceOffering
QoS metrics 13 Latency, Jitter, PacketLoss, Throughput, IOPS
Storage 13 BlockStorageConfiguration, ReplicationPolicy, SnapshotPolicy
Data products 13 DataProduct, DataProductCatalogue, EvidenceTemplate
Trust framework 10 Ecosystem, EcoTrustScope, EcoTSP, CompliantCredential
+ identifiers, measurement, FaaS, environmental, and more ~19 VatID, EORI, EnergyMix, WaterUsageEffectiveness

Every model ships the full set of Candidates artifacts: a JSON Schema, an NGSI-LD @context, and all four example serializations (NGSI-v2 and NGSI-LD, key-values and normalized) — each validated against its own schema.

Translation notes

  • Names preserved verbatim. Gaia-X’s own class and property names (hasPoint-style camelCase, PascalCase classes) are kept exactly as the ontology defines them — no forced renaming.
  • Cross-references become NGSI-LD Relationships. Any property whose range is another Gaia-X class (e.g. Datacenter.aggregationOfResources → AvailabilityZone) is modeled as a Relationship, not an inlined object, so the resulting graph mirrors the ontology’s own linking structure.
  • Inheritance is flattened, not duplicated in text. A subclass’s schema only lists its own properties; inherited ones are documented on the parent model and referenced by name in the description, matching how the source ontology itself organizes properties.
  • Open vocabularies stay open. A number of Gaia-X properties reference controlled vocabularies (e.g. DiskType, HypervisorType) that aren’t enumerated on the class documentation pages themselves; those are modeled as open strings with a note in the description rather than an invented closed enum.
  • One naming collision, resolved explicitly. DataUsageAgreement‘s own dataProvider property (the participant providing a Data Product) would collide with the Candidates convention’s boilerplate dataProvider metadata field (harmonised-data-entity provider). It’s exposed as gxDataProvider instead, with the substitution documented in the schema’s own description.

Try it, and tell us what’s missing

This is a Candidate — a first, carefully-sourced translation, not yet promoted to an official Smart Data Models subject. A few things are open and would benefit from community input before that step:

  • Overlap with existing Smart Data Models subjects (dataModel.Device, generic infrastructure/building vocabularies) hasn’t been checked in detail.
  • License terms for the specific v2111 release should be confirmed before promotion out of Candidates.
  • A handful of controlled vocabularies referenced by the ontology (e.g. disk/hypervisor/firmware type enumerations) aren’t resolved to closed lists yet — see the individual schema descriptions for which ones.

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

European Union Agency for Railways (ERA) available in the candidates repository

  By

Smart Data Models’ Candidates repository now includes four new candidate standards translated from the European Union Agency for Railways (ERA) Ontology v3.3.3 — the shared data model behind the EU’s four railway interoperability registers. Together they bring 74 entity types covering the physical rail network, authorised rolling stock, certification records, and individual vehicles into the NGSI-LD / NGSI-v2 world.

era-eradis: 14 candidate models from ERA ERADIS v3.3.3
era-eratv:  8 candidate models from ERA ERATV v3.3.3
era-evr: 14 candidate models from ERA EVR v3.3.3
era-rinf: 38 candidate models from ERA RINF v3.3.3

Candidates are data models translated/transformed from open standards that are only missing that real examples would qualify them to be officially published.  so if you are using any of the candidates you can contact us in this mail adn we will start the process to make them official.

Mind that the ERA data models (from a previous version are already available in the official repository)

New data models mapping OpenStreetMap

  By

Fifteen new data models from the mapping of OpenStreetMap are now available in a new subject datamodel.OpenStreetMap

Thanks to the inspiration of Flavio Cirillo who currently works for NEC these models are now available, and thanks to the contributors of OpenStreetMap who created these models that are mapped here in this derivative work.

New data models will come shortly for this new subject

  • OSMAerialway. An aerial transport or lift from OpenStreetMap tagged with aerialway=*. Describes cable cars, gondolas, chair lifts, and drag lifts

  • OSMAmenity. A facility or amenity from OpenStreetMap tagged with amenity=*. Represents places of public or private use such as restaurants, schools, hospitals, banks, etc

  • OSMBuilding. A building or group of connected buildings from OpenStreetMap tagged with building=*. Represents the physical structure of a building, including its geometry, dimensions, materials, and functional classification. For specific functions within a building (shop, amenity, etc.) additional entities should be used.

  • OSMBuildingPart. A part or section of a building from OpenStreetMap tagged with building:part=*. Used to represent buildings with varying heights, roof shapes, or materials across different sections, enabling 3D building visualisation (Simple 3D Buildings standard).

  • OSMCycleRoute. A dedicated cycling infrastructure element from OpenStreetMap. Represents cycle paths, shared cycle lanes, and bike routes tagged with highway=cycleway or cycleway=* on road ways.

  • OSMHighway. A road or path element from OpenStreetMap tagged with the highway key. Represents all types of roads, from motorways to footpaths, as defined by the OSM highway taxonomy.

  • OSMLanduse. An area of land use from OpenStreetMap tagged with landuse=*. Describes the primary human purpose or use of an area of land

  • OSMLeisure. A place for leisure, sports, or recreation from OpenStreetMap tagged with leisure=*. Includes parks, sports pitches, swimming pools, stadiums, etc

  • OSMNatural. A natural feature from OpenStreetMap tagged with natural=*. Describes geographical features such as water bodies, woods, scrub, peaks, beaches, etc

  • OSMParkingArea. A vehicle parking area or facility from OpenStreetMap tagged with amenity=parking. Represents surface car parks, multi-storey garages, underground facilities, and other organised parking areas.

  • OSMPublicTransportStop. A public transport stop, station, platform or boarding point from OpenStreetMap. Represents nodes and areas where passengers board or alight from public transport services, tagged with public_transport=* or specific mode tags.

  • OSMRailway. A railway track or infrastructure element from OpenStreetMap tagged with the railway key. Covers all types of rail infrastructure, from mainline heavy rail to trams, subways and funiculars.

  • OSMShop. A shop or retail store from OpenStreetMap tagged with shop=*. Represents establishments selling retail products directly to end customers

  • OSMTourism. A tourist attraction or tourism-related facility from OpenStreetMap tagged with tourism=*. Includes hotels, museums, viewpoints, artworks, etc

  • OSMWaterway. A waterway from OpenStreetMap tagged with waterway=*. Describes rivers, streams, canals, drains, and other water courses