Digital Twin Ontologies: DTDL vs NGSI-LD vs AAS (2026)

Q: What is the difference between DTDL, NGSI-LD and the Asset Administration Shell?

DTDL is Microsoft's JSON-LD modelling language for typing twins in Azure Digital Twins, with six metamodel classes: Interface, Telemetry, Property, Command, Relationship and Component. NGSI-LD is an ETSI standard (GS CIM 009) defining a JSON-LD property graph of entities, properties and relationships plus a context broker API, used mainly by cities and public data spaces. The Asset Administration Shell is the IDTA's industrial standard for describing an asset's identity, nameplate and documents across its lifecycle so companies can exchange it, and it is the format positioned to carry the digital product passport.

Q: Should I build my digital twin in the platform's native modelling language?

Only if you have no external readers and no plausible platform change within the twin's life. The platform-native language is fine as a projection, but when it is the only definition of your asset types, the first regulator, supplier, customer or city that needs to read the twin forces a second model and a mapping nobody budgeted. Keep a canonical model in the standard your readers use, under version control with a named owner, and generate the platform's language from it in CI.

Q: How does the EU digital product passport affect digital twin data models?

A product passport is a twin of a product that someone outside the company must read through a QR code. Regulation (EU) 2023/1542 requires a battery passport from 18 February 2027 for light-means-of-transport batteries, industrial batteries above 2 kWh and electric vehicle batteries, and Regulation (EU) 2024/1781 generalises the passport and requires a Commission registry of passport identifiers by 19 July 2026. Companies whose asset data lives only in a platform-native model now need an exchange-format projection, typically an Asset Administration Shell submodel, and the mapping should be tested in 2026.

Q: What are the practical limits of DTDL v3 I should know before modelling in it?

Per the specification, an Interface's extends hierarchy allows at most 1,024 Interfaces and a depth of 10 levels; each Interface definition is capped at 1 MiB of text; the contents hierarchy including inherited elements is capped at 100,000 elements; complex schemas nest to a depth of 5; and in v3 a Component cannot contain another Component. Deep RDF ontologies therefore need a documented flattening rule when they are projected into DTDL, and interface identifiers carry a major.minor version in which minor changes should be strictly additive.

Q: When should a city or public body use NGSI-LD for its twin?

When the twin must be read by other public bodies, vendors and citizens through a standard context broker API, which is exactly what NGSI-LD standardises. ETSI GS CIM 009 V1.8.1, published March 2024, defines the entity, property and relationship model, subscriptions and temporal queries. The honest limit is that the API is the standard and the data models are community contributions of uneven depth, so a city adopting NGSI-LD still has to choose or write the models for its domains and should budget that work rather than assume the standard arrives complete.

Q: Is the Asset Administration Shell a digital twin platform?

No. The AAS, specified by the IDTA with Part 1 metamodel version 3.1.1 published in July 2025, describes an asset for exchange between companies: identity, nameplate, technical data, documents and other standardised submodels, serialised as JSON, XML or an AASX package. It does not hold the live operational graph of relationships between assets or the streaming telemetry that a twin platform manages. Use the AAS as the exchange format and passport carrier, generated from your canonical model, and keep the operational twin on a platform built for state and relationships.

Q: What is Brick and when does it beat a platform ontology for buildings?

Brick is an open Semantic Web ontology, maintained by the Brick Consortium, that standardises how physical, logical and virtual building assets and the relationships between them are described, covering HVAC, lighting, metering and spatial structure across vendors. It beats a platform-native building model when the portfolio owner expects to change analytics vendors, energy service companies or building management systems over the building's life, because the next vendor can read a Brick graph without re-tagging every point. Microsoft's RealEstateCore DTDL ontology serves the same portability goal inside Azure Digital Twins.

Q: How do you version a digital twin ontology without breaking every consumer?

Treat the canonical model like a data contract. Keep it in a repository, give every class and interface a major.minor version, make minor changes strictly additive, reserve major versions for removals and renames with a written migration, and run CI that regenerates every platform projection and fails on a breaking change against a registered consumer. Record the mapping version on every exchanged document such as an AAS package or passport view, so that a document read years later can be traced to the model that produced it. The projection is a build artefact; the canonical model is what you version.

Satyam Kumar

Zurück zum Blog

architecture

Digital Twin Data Models and Ontologies: The Ontology Is the Twin, So Choose It by Who Must Read the Twin From Outside, Not by the Platform You Run (2026)

By Satyam KumarOctober 20, 202617 min read

digital twin ontology digital twin data model dtdl ngsi-ld asset administration shell aas submodels brick schema realestatecore azure digital twins models aws iot twinmaker eclipse ditto w3c thing description digital product passport battery passport 2027 industry 4.0 interoperability semantic interoperability

Digital Twin Data Models and Ontologies: The Ontology Is the Twin, So Choose It by Who Must Read the Twin From Outside, Not by the Platform You Run (2026)

Frequently Asked Questions

Artikel teilen

Twitter LinkedIn WhatsApp

Satyam Kumar

Founder & AI Architect, AppScale LLP

KI & Cloud Architekt. Ich helfe Teams, Systeme zu bauen, die auf Millionen skalieren.

LinkedIn GitHub

Digital Twin Data Models and Ontologies: The Ontology Is the Twin, So Choose It by Who Must Read the Twin From Outside, Not by the Platform You Run (2026)

Frequently Asked Questions

Artikel teilen

Comments

Leave a comment