Hello everyone,
As we are evaluating the upcoming Civitas Core V2 and exploring the implementation of NGSI-LD for Local Digital Twins (LDTs), I want to open a discussion about a fundamental but critical topic: Unique Identifiers (URNs).
For my master’s thesis and our ongoing smart city projects, we’ve been testing scenarios for „truly federated“ digital twins based on Minimal Interoperability Mechanisms (MIMs). A core requirement (MIM1) is that every entity within the system must have a universally unique identifier.
Currently, without a strict naming convention, different domains, tenants, and external systems tend to generate conflicting or opaque identifiers (e.g., overlapping numeric IDs, untraceable UUIDs, or localized formats like 123/2026). This leads to data silos, prevents cross-domain linking, and causes fatal collisions when we try to federate data from multiple sources (e.g., city council, utility companies, external contractors).
The Proposed Solution
To solve this, I propose adopting a strict, five-segment URN structure for all NGSI-LD entities within the Civitas/Core V2 platform:
Format:
urn:ngsi-ld:{EntityType}:{DataOwner}:{EntitySubtype}:{UniqueId}
Example:
urn:ngsi-ld:Equipment:gov_boston:lamp:1024
Structure Breakdown:
-
urn:ngsi-ld: (Machine Prefix): The static prefix ensuring adherence to the global ETSI NGSI-LD standard.
-
{EntityType} (The World/Domain): Broad classification in PascalCase (e.g., Device, Equipment, Building, Contract). Ideally mapped to global ontologies like Smart Data Models.
-
{DataOwner} (The Digital Stamp): Identifies the organization responsible for the data. Formatted as a reverse-domain (e.g., gov_boston or digital_civitasconnect). This is the core mechanism that enables multi-tenancy and federation.
-
{EntitySubtype} (Agenda/Classifier): A kebab-case abbreviation grouping similar items (e.g., lamp, air-sensor, invoice).
-
{UniqueId} (Local ID): The specific, local identifier (e.g., 1024, 2026-145).
Key Benefits for Civitas Core V2
-
Guaranteed Uniqueness Across Federation: If a city and a private contractor both have a lamp with local ID 1024, the {DataOwner} segment ensures they never conflict when data spaces are merged.
-
Semantic Clarity: Unlike opaque UUIDs (e.g., 550e8400-e…), this format is highly human-readable. A developer, data scientist, or even an AI assistant can immediately look at the URN and know exactly what it is and who owns it.
-
Stable and Immutable: The URN represents the physical essence of the object. Volatile properties (like its current street location or current owner) are modeled as entity relationships, not embedded in the ID.
-
AI & Automation Ready: A standardized structure makes it incredibly easy to build integrations. For example, we successfully tested an MCP Server connected to an AI assistant (Claude/Copilot) that could effortlessly read, validate, and display NGSI-LD data directly from the context broker, simply because the entity structures and URNs were predictable.
Trade-offs to consider
-
Identifiers are longer than simple integers.
-
Requires a bit of governance (or automated validation) to ensure {EntitySubtype} abbreviations remain consistent.
-
Legacy systems using invalid characters (like / or spaces) will need their IDs transformed (e.g., replacing slashes with hyphens) to remain URL-safe.
-
Alternatively, should we consider generating identifiers using DIDs? If we do, we lose the ability to easily map data from existing legacy systems to NGSI-LD. Furthermore, if a company loses the private key that controls their did:key:z6M…, they lose their verifiable proof of ownership. On the other hand, implementing DIDs ensures that external parties can cryptographically trust the ownership of the ID, which is a major benefit to consider. However, I suppose that when data needs to be verified, it will typically be fetched directly from the municipality’s public Context Broker API endpoint anyway, which inherently provides an institutional layer of trust.
I strongly believe that implementing this standard natively in V2 will save municipalities massive headaches regarding data silos and make cross-departmental analytics a breeze.
I would love to hear your thoughts on this! How are you currently handling entity identifiers in your local setups? Would this structure fit your municipality’s needs?
Best regards,
Marek Mráz
( ETSI GS CIM 009 and ETSI GS CIM 020 )
