Data models

This is the layer that turns data into knowledge, and it is the one most projects underestimate.

A data format says the value is 21.6. A data model says it is a temperature, in Celsius, observed at a particular time, by a sensor belonging to Room 101. One of those you can put in a chart. The other you can ask questions of: which rooms on the north side run cold, which meters belong to which tenant, what does this building actually cost to heat.

What a model adds

Three things a bare payload does not have:

• Identity. A stable, unique reference for the thing, so two systems agree they mean the same sensor.
• Meaning. What the value is, in what unit, measured when.
• Relationships. What the thing belongs to, contains or serves, so data can be navigated rather than only listed.

The three you will meet

	NGSI-LD	RealEstateCore	Open BIM (IFC)
Focus	IoT data and semantic integration	Digital twin with semantics	Building structure and components
Format	JSON-LD, RDF	DTDL, JSON-LD	IFC/EXPRESS, BCF
Real-time data	Yes, primarily sensor data	Yes, can include sensors	No, static
Relationships	Entities, properties, relationships	Entities and relationships	Object-based hierarchies
Used for	IoT platforms, smart buildings	Building digitalization and analysis	Design, construction, collaboration

Open BIM is the building's static digital model. RealEstateCore and NGSI-LD carry dynamic semantic data and sensor readings. Smart buildings often use Open BIM as the foundation with NGSI-LD or RealEstateCore above it for the live data.

NGSI-LD

NGSI-LD is the model built for IoT data. Everything is an entity with an id, a type, properties and relationships.

It comes in two forms carrying the same information.

The key-value, or flat, form is compact and easy to read:

{
  "id": "urn:ngsi-ld:TemperatureSensor:001",
  "type": "TemperatureSensor",
  "temperature": 21.6,
  "unitCode": "CEL",
  "observedAt": "2025-09-16T13:00:00Z",
  "isPointOf": "urn:ngsi-ld:Room:101"
}

The normalized form makes each property an object with its own metadata, which is more verbose and more precise:

{
  "id": "urn:ngsi-ld:TemperatureSensor:001",
  "type": "TemperatureSensor",
  "temperature": {
    "type": "Property",
    "value": 21.6,
    "unitCode": "CEL",
    "observedAt": "2025-09-16T13:00:00Z"
  },
  "isPointOf": {
    "type": "Relationship",
    "object": "urn:ngsi-ld:Room:101"
  }
}

Reading the fields:

• id uniquely identifies the entity. The urn:ngsi-ld: prefix is a convention that keeps identifiers unique across systems.
• type is the kind of entity, here a temperature sensor.
• value is the measurement.
• unitCode is the unit, using the standard code list, where CEL is degrees Celsius.
• observedAt is when the measurement was taken, which is not the same as when it arrived.
• isPointOf is a relationship, tying the sensor to the room it measures.

The distinction between a property and a relationship is the heart of the model. A property has a value; a relationship points at another entity. Follow enough relationships and you can walk from a reading to the room, to the floor, to the building, to the owner.

Yggio uses the flat NGSI-LD form, with attributes held in translator attributes. That choice matters: it means Yggio is not locked to one vocabulary, and can carry arbitrary data models rather than forcing every project through a single fixed one.

RealEstateCore

RealEstateCore is a digital twin model for buildings, expressed in DTDL or JSON-LD. It describes the building and its equipment as well as the readings, and is widely used in property management.

{
  "@context": [
    "https://w3id.org/rec/v1.0",
    "https://www.w3.org/2019/10/td/v1",
    "https://w3id.org/rec/rec-vocab"
  ],
  "@type": "Temperature_Sensor",
  "id": "urn:rec:TemperatureSensor:001",
  "lastKnownValue": {
    "@type": "TemperatureObservation",
    "value": 21.6,
    "unitCode": "CEL",
    "observedAt": "2025-09-16T13:00:00Z"
  },
  "isPointOf": {
    "@type": "Room",
    "id": "urn:rec:Room:101"
  }
}

The @context names the vocabularies the document draws on, which is what makes the type names mean something specific rather than being local labels.

Much of the conversion between RealEstateCore and NGSI-LD can be automated. Basic sensor and room data maps straightforwardly; more complex building structures need adapting.

Yggio has connectors that transform NGSI-LD into RealEstateCore, so the same readings can serve an IoT team and a property team in the shape each of them expects.

Open BIM

Open BIM is a different kind of thing, and confusing it with the other two causes real trouble in projects. It models buildings statically, for file-based interoperability, rather than carrying live data.

• Focus: a standardized representation of buildings, their components and their properties.
• Formats: IFC (Industry Foundation Classes), the most widely used, based on the EXPRESS schema; and BCF (BIM Collaboration Format), for communicating issues and changes between BIM applications.
• Content: architecture, structure and installations such as HVAC, plumbing and electrical, plus metadata about components including dimensions, materials and placement.

Its relationship to IoT is that Open BIM describes the building, and IoT data is linked to it through references to sensors. The Open BIM file itself holds no live values, so a question like "what is the temperature in this room now" is answered by the IoT platform, using the Open BIM model to know which room is which.

Choosing and combining

You will usually not choose one. A working smart building has the static model from design and construction, the semantic building model for operations, and the IoT model for live data, with identifiers linking them.

What matters in practice:

1. Agree the identifiers first. Everything else can be converted; identity cannot be reconstructed afterwards.
2. Record the unit and the observation time with every value, always.
3. Keep the relationships, even if the first application does not use them. They are what makes the second and third application cheap.