IoT Data Models and Interoperability

Introduction

An Internet of Things (IoT) solution rarely consists of devices from one manufacturer or one software platform. A temperature sensor may publish data through MQTT, a gateway may transform it into JSON, a cloud service may store it in a time-series database, and an enterprise maintenance system may require XML or a semantic API. Although these systems can communicate at the network level, communication alone does not guarantee that they understand one another.

Interoperability is the ability of different devices, applications, networks and organisations to exchange information and use the exchanged information correctly. IoT interoperability therefore involves more than selecting a communication protocol. It requires agreement about data structure, meaning, identity, units, timing, security and operational context.

This chapter examines common IoT data representations—JSON, XML and CBOR—and introduces schemas, metadata, APIs, semantic models and ontologies. It also explains how standards and design practices help integrate heterogeneous devices with platforms and enterprise systems.

Learning Objectives

After studying this chapter, the learner should be able to:

1. Explain syntactic, structural, semantic and organisational interoperability.
2. Represent IoT observations using JSON, XML and CBOR.
3. Compare the strengths and limitations of common data formats.
4. Use schemas and metadata to validate and interpret device data.
5. Explain ontologies, semantic models and linked data in IoT.
6. Design an API-oriented integration between devices, platforms and enterprise applications.
7. Identify governance, security, privacy and data-quality issues in interoperable IoT systems.

1. Interoperability as a Layered Problem

IoT interoperability can be considered at several levels:

A system may be syntactically interoperable but semantically incompatible. For example, two systems may exchange a field named value, but one records degrees Celsius and the other records degrees Fahrenheit. The message is readable, yet the interpretation is unsafe.

A useful principle is that every important observation should communicate at least:

• what was observed;
• the measured value and unit;
• which property or phenomenon was measured;
• where and when it was measured;
• which device or sensor produced it;
• the quality or uncertainty of the observation; and
• how the observation can be related to an asset or business process.

2. IoT Observations and Data Models

An observation is a statement about a property at a particular time and, often, location. A simple model can be written as:

The expression is a conceptual tuple rather than a transmission format. id identifies the observation, phenomenon identifies what is measured, value is the result, unit gives its measurement unit, time identifies when it applies, location gives spatial context, source identifies the device or process, and quality records confidence or validity information.

This model distinguishes three related concepts:

• Entity: a physical or logical object, such as a pump or building.
• Property: a characteristic of an entity, such as pressure or occupancy.
• Observation: a value assigned to a property at a time, such as 4.2 bar at 10:00.

A data model defines entities, attributes, relationships and constraints. A data format defines how that model is encoded for storage or transmission. JSON and XML are formats; an observation model is a conceptual representation. Confusing these levels often produces systems that exchange valid syntax but lack shared meaning.

2.1 Data types and units

IoT data may include integers, decimal values, Boolean states, strings, enumerations, arrays, binary data and timestamps. A data model should specify whether a value is continuous or discrete, whether it may be absent, and what range is valid.

Units must be explicit. A value of 25 is incomplete if the receiving system does not know whether it means 25 °C, 25 °F or 25 K. Unit conversion should occur at a clearly defined boundary, preferably using a recognised unit vocabulary. Temperature conversion, for example, is not a simple scaling operation:

Here, T_°C and T_°F are temperature readings expressed in degrees Celsius and degrees Fahrenheit. The formula applies to temperature scales with the stated reference relationship; it must not be applied to temperature differences without care, because a difference of 1 °C equals a difference of 1.8 °F, while absolute temperature conversion includes the offset 32.

3. JSON for IoT Data Exchange

JavaScript Object Notation (JSON) represents data using objects, arrays, strings, numbers, Boolean values and null. It is widely used in REST APIs, cloud services and gateway software because it is compact enough for many applications and easy for people to read.

An observation in JSON might be represented as follows:

{
  "observationId": "obs-84321",
  "property": "airTemperature",
  "value": 23.6,
  "unit": "°C",
  "timestamp": "2025-03-08T10:15:00Z",
  "deviceId": "room-2-sensor-7",
  "location": {
    "building": "B1",
    "room": "R2"
  },
  "quality": "valid"
}

The example uses an ISO 8601-compatible UTC timestamp. The suffix Z indicates Coordinated Universal Time. In production, the data contract should specify timestamp precision, clock synchronisation expectations and whether timestamps describe event time, measurement time or ingestion time.

Advantages of JSON

• Broad support in programming languages and web frameworks.
• Human readability, which simplifies testing and troubleshooting.
• Natural representation of nested objects and arrays.
• Good fit for HTTP APIs and cloud integration.

Limitations of JSON

• Field names are repeated, increasing message size.
• Standard JSON has limited native typing for dates, binary values and decimal precision.
• A JSON document does not automatically explain the meaning of its fields.
• Flexible structure can lead to incompatible versions if contracts are poorly governed.

JSON is therefore a representation, not a complete interoperability solution. A documented schema, vocabulary and versioning policy are still required.

4. XML for Structured and Enterprise Integration

Extensible Markup Language (XML) represents data with elements and attributes. It supports namespaces, document structure, validation and extensive enterprise tooling.

<Observation xmlns="https://example.org/iot/observation">
  <observationId>obs-84321</observationId>
  <property>airTemperature</property>
  <value unit="°C">23.6</value>
  <timestamp>2025-03-08T10:15:00Z</timestamp>
  <deviceId>room-2-sensor-7</deviceId>
</Observation>

XML is useful when systems require formal document contracts, namespaces, digital signatures, transformation languages or established enterprise standards. It is common in business-to-business integration and systems built around SOAP or XML-based regulatory interfaces.

Its disadvantages include verbosity, processing overhead and greater implementation complexity than JSON for simple services. XML security also requires careful configuration because unsafe parsers can be exposed to attacks such as external entity expansion. XML should be selected because its capabilities are needed, not merely because it is familiar.

5. CBOR for Constrained Devices

Concise Binary Object Representation (CBOR) is a binary format designed to represent data-model values efficiently while retaining a structure similar to JSON. It is standardised by the Internet Engineering Task Force and is particularly relevant to constrained devices and low-bandwidth networks.

CBOR can represent integers, floating-point numbers, text, byte strings, arrays, maps, tags and other types more directly than JSON. It usually reduces transmission size and parsing overhead, although the exact result depends on field names, values and implementation.

A CBOR message is not normally written as readable text. During development, it may be shown in diagnostic notation, conceptually similar to:

{
  "property": "airTemperature",
  "value": 23.6,
  "unit": "°C",
  "timestamp": "2025-03-08T10:15:00Z"
}

The transmitted representation is binary even when a diagnostic tool displays it as text. CBOR is often paired with CoAP in constrained environments, but the two are separate: CBOR is a data format, whereas CoAP is an application-layer protocol.

Comparison of representations

The same conceptual model can be encoded in all three formats. Interoperability is preserved only if the semantics, constraints and mappings are also preserved.

6. Schemas, Validation and Versioning

A schema is a machine-readable or formally documented description of permitted structure, data types, required fields, constraints and relationships. Validation checks whether an instance conforms to that description.

For JSON, a schema might require:

• observationId to be a string;
• value to be a number;
• unit to be a permitted unit identifier;
• timestamp to follow a defined date-time format; and
• property to belong to an approved vocabulary.

For XML, XML Schema Definition (XSD) can define elements, attributes, data types, cardinality and namespaces. For CBOR-oriented systems, Concise Data Definition Language (CDDL) can describe the expected data model.

Validation is not the same as correctness. A schema may verify that value is numeric, but it cannot always determine whether the sensor is calibrated or whether the value belongs to the stated device. Consequently, IoT systems need several forms of validation:

1. Syntactic validation: Is the message well formed?
2. Structural validation: Does it conform to the schema?
3. Domain validation: Is the value within an acceptable range and unit?
4. Temporal validation: Is the timestamp plausible and ordered correctly?
5. Contextual validation: Is the reading appropriate for the device and operating state?

Versioning strategies

Schemas evolve as systems mature. Safe practices include:

• adding optional fields rather than changing the meaning of existing fields;
• retaining stable identifiers;
• publishing explicit major and minor versions;
• documenting deprecated fields and their removal dates;
• using content negotiation or endpoint versioning where necessary; and
• testing old and new producers and consumers together.

A breaking change is one that causes a conforming consumer to fail or interpret existing data differently. Renaming a required field or changing Celsius to Fahrenheit without changing the contract is breaking. Adding an optional diagnostic field is usually backward compatible.

7. Metadata and Context

Metadata is data about data. In IoT, metadata may describe a device, sensor capability, location, unit, accuracy, sampling interval, firmware version, owner, access policy or provenance.

For a temperature sensor, useful metadata includes:

• sensor type and manufacturer;
• measurement range, such as −40 °C to 125 °C;
• stated accuracy and calibration date;
• location and installation orientation;
• sampling and reporting intervals;
• battery status and firmware version; and
• the property and unit being measured.

Metadata should not be treated as optional decoration. Without it, a stream of values becomes difficult to discover, compare, govern or reuse. A platform may store a sensor reading for years, while the device itself is replaced. Persistent metadata and provenance allow later users to determine what the historical data means.

Important distinctions include:

• Event time: when the phenomenon occurred or was measured.
• Ingestion time: when a platform received the message.
• Processing time: when an application transformed it.
• Provenance: the chain of sources and transformations through which data passed.

These times can differ because of buffering, network delays and intermittent connectivity. Analytics and control applications must use the appropriate time.

8. Semantic Models and Ontologies

A semantic model defines concepts and relationships in a domain. An ontology goes further by formally specifying concepts, properties, relationships and sometimes logical constraints so that software can reason over them.

For example, an ontology may state that:

• a TemperatureSensor is a type of Sensor;
• a sensor observes an AirTemperature property;
• a sensor is located in a Room;
• a room is part of a Building; and
• a temperature value has a unit from an approved unit system.

This information enables discovery queries such as “find all sensors measuring air temperature in buildings managed by Department A.” The query does not need to depend on a vendor-specific field called temp_1.

Semantic interoperability commonly uses:

• globally unique identifiers, often URI-like identifiers;
• controlled vocabularies for properties, units and states;
• RDF-style triples consisting of subject, predicate and object;
• ontology languages such as OWL for richer relationships; and
• query mechanisms such as SPARQL in systems that expose graph data.

A triple can be expressed conceptually as:

sensor-7  observes  air-temperature
sensor-7  locatedIn room-2
observation-84321  hasValue  23.6

Semantic technology does not eliminate the need for ordinary data formats. JSON-LD, for example, combines JSON syntax with links to semantic vocabularies. A practical system may use JSON for transport, JSON Schema for structure and an ontology for meaning.

Semantic mapping

Heterogeneous systems rarely share an ontology completely. Mapping is therefore required. A gateway might map temp, temperature, and airTemperature to one canonical concept, while converting units and preserving the original field as provenance.

Mappings should be explicit, testable and governed. Automatic matching based only on similar names is risky because the same term can have different scopes. Human review is particularly important for safety-critical data.

9. APIs and Integration Architecture

An API is a defined interface through which software requests or publishes capabilities and data. IoT APIs may support:

• device registration and discovery;
• telemetry ingestion;
• command and control;
• historical data queries;
• event subscriptions and notifications;
• digital-twin access; and
• identity, authorisation and audit operations.

A REST API commonly uses HTTP methods such as GET, POST, PUT and DELETE. MQTT uses topics and publish/subscribe interaction, while CoAP provides a constrained web-style interaction model. These mechanisms can carry different representations, including JSON, XML or CBOR.

A reliable integration should specify:

1. endpoint or topic names;
2. message schema and semantic vocabulary;
3. authentication and authorisation requirements;
4. delivery, retry and duplicate-handling behaviour;
5. timestamp and ordering rules;
6. error codes and diagnostic responses;
7. rate limits and payload-size limits; and
8. version and deprecation policy.

Canonical and translation models

There are two common integration strategies. In a point-to-point model, each system translates directly to every other system. If there are n systems, the number of possible directed mappings can approach n(n − 1), which grows rapidly and becomes difficult to govern.

A canonical model introduces one shared internal representation. Each system maps to and from the canonical model, requiring approximately 2n mappings for n systems, assuming one inbound and one outbound mapping per system. This is a conceptual comparison, not a universal engineering law: real systems may require multiple versions, domains and protocols. A canonical model reduces integration complexity but can become a bottleneck if it is too rigid or owned by one vendor.

10. Applied Case: Smart Cold-Storage Monitoring

Background

The following is an illustrative case. A food distribution company operates refrigerated storage rooms at several sites. Existing equipment includes temperature sensors from three vendors, a gateway using MQTT, a cloud platform with a JSON API, and an enterprise maintenance system that accepts XML.

Problem

The systems report similar information with inconsistent names and units. One vendor sends temp in Fahrenheit, another sends temperature in Celsius, and a third sends an integer representing tenths of a degree Celsius. Timestamps are variously local time and UTC. The maintenance system cannot reliably determine which sensor produced an alarm or which refrigeration unit is affected.

Analysis

The company identifies the following interoperability requirements:

• a common observation model;
• stable identifiers for sites, rooms, sensors and refrigeration units;
• explicit units and UTC timestamps;
• metadata for calibration and operating range;
• quality states for missing or suspect readings;
• an alarm model with severity and acknowledgement; and
• mappings to the maintenance system’s asset identifiers.

Approach and solution

A gateway performs protocol and format translation but does not discard the original message. It creates a canonical observation containing property, value, unit, observedAt, sensorId, roomId, assetId and quality. Vendor-specific fields are retained in a provenance section.

The gateway converts Fahrenheit values using:

For example, a reading of 41 °F becomes:

The transformation records the conversion method and source unit. A schema validates required fields, while a controlled vocabulary identifies the property as air temperature. A semantic mapping links the room to the refrigeration asset. The cloud API exposes JSON for ordinary applications and a subscription for alarms. An XML adapter maps canonical alarms into the maintenance system’s required document structure.

Outcome

The enterprise system receives consistent alarms and can associate them with assets and locations. Engineers can compare historical data across vendors, while auditors can inspect provenance. The company also discovers that several devices have outdated calibration records, demonstrating that interoperability can expose governance problems rather than merely solve formatting problems.

Learning points

1. Translation must preserve meaning, not only syntax.
2. Unit conversion and timestamp normalisation require explicit rules.
3. Metadata is essential for interpreting historical data.
4. A canonical model is useful when many systems must cooperate.
5. Provenance allows organisations to verify transformations and responsibility.

11. Security, Privacy and Governance

Interoperability increases the number of systems that can access data and therefore expands the attack surface. Security controls should include authenticated devices, encrypted transport, authorisation by role or capability, credential rotation, secure API gateways and audit logging.

Data models should distinguish telemetry from commands. A temperature reading may be broadly shareable within a facility, whereas a command to disable refrigeration requires stronger authorisation and safety controls. Message integrity and replay protection are especially important for control operations.

IoT data may reveal occupancy, work patterns, health conditions or industrial processes. Data minimisation, purpose limitation, retention rules and access reviews should be applied where personal or commercially sensitive information is involved. Device identifiers can become personal data when they are linked to individuals or locations.

Governance responsibilities should identify who owns the data, who may modify metadata, who approves vocabulary changes, how long data is retained and how incidents are reported. Standards and specifications improve interoperability, but they do not replace organisational agreements.

12. Challenges and Limitations

Heterogeneity

Devices differ in hardware, operating systems, protocols, precision and lifecycle. A single universal model may be impractical. Domain profiles and adapters are often needed.

Resource constraints

Small devices have limited memory, processor capacity, energy and bandwidth. Human-readable JSON may be convenient but inefficient for every sensor transmission. CBOR or compact binary encodings may be preferable, with translation at a gateway.

Ambiguous semantics

Natural-language labels are not reliable identifiers. “Pressure” might mean line pressure, atmospheric pressure or differential pressure. Controlled vocabularies and context are necessary.

Data quality

Interoperable data can still be inaccurate, duplicated, delayed or incomplete. Quality indicators, validation rules and monitoring are required.

Version drift

Vendors may change payloads without adequate notice. Contract testing, schema registries and compatibility testing reduce this risk.

Centralisation risk

A canonical platform can simplify integration but may create dependency on one provider. Open specifications, export capabilities and documented mappings help preserve portability.

13. Best Practices and Contemporary Directions

A professional IoT data design should follow these practices:

• define the conceptual data model before selecting an encoding;
• make units, timestamps, identifiers and quality explicit;
• use schemas for structural validation;
• use controlled vocabularies and ontologies for meaning;
• separate event data from device and asset metadata;
• preserve provenance through transformations;
• design for backward-compatible evolution;
• validate data at device, gateway and platform boundaries;
• test with malformed, delayed, duplicated and out-of-range messages;
• document APIs using a machine-readable contract; and
• apply security and privacy requirements from the beginning.

Contemporary IoT platforms increasingly use digital twins, semantic APIs, edge processing and event-driven architectures. Digital twins maintain software representations of physical assets and their relationships. Edge systems reduce latency and bandwidth use by filtering or aggregating data near the source. Machine learning can detect anomalies, but models are only as dependable as the units, timestamps, provenance and quality of their input data. AI does not remove the need for sound data modelling; it makes that need more important.

Chapter Summary

IoT interoperability requires shared understanding at technical, syntactic, structural, semantic and organisational levels. JSON is convenient and widely supported, XML provides formal document and namespace capabilities, and CBOR offers compact binary representation for constrained environments. None of these formats, by itself, guarantees meaningful integration.

A sound IoT data model identifies entities, properties, observations, values, units, time, location, source and quality. Schemas validate structure, metadata provides context, and ontologies and controlled vocabularies provide shared meaning. APIs expose data, commands and discovery functions, while gateways and canonical models help connect heterogeneous systems.

Successful integration also depends on versioning, provenance, security, privacy, governance and data-quality controls. The central professional principle is to preserve meaning throughout every transformation—from sensor to gateway, platform, analytics service and enterprise application.

Key Terms

Interoperability: The ability of different systems to exchange and correctly use information.

Syntactic interoperability: Agreement on message encoding and representation.

Semantic interoperability: Agreement on the meaning of exchanged data.

Data model: A description of entities, attributes, relationships and constraints.

Observation: A time- and context-related result about a property.

JSON: A text-based notation using objects, arrays and primitive values.

XML: A tagged text format supporting structured documents and namespaces.

CBOR: A compact binary representation of structured data.

Schema: A definition of permitted structure, types and constraints.

Metadata: Data that describes other data, devices or processes.

Ontology: A formal specification of concepts and relationships in a domain.

Vocabulary: An agreed set of terms and identifiers.

Provenance: Information about the origin and transformation history of data.

Canonical model: A shared internal representation used by multiple systems.

API: A defined software interface for requesting or exchanging capabilities and data.

Event time: The time at which a measurement or event occurred.

Ingestion time: The time at which a system received data.

Digital twin: A software representation of a physical asset or process.

Schema validation: Testing whether an instance conforms to a defined schema.

Review Questions

Short Answer Questions

1. Distinguish syntactic interoperability from semantic interoperability.
2. Why should an IoT observation include a unit and timestamp?
3. State two advantages and two limitations of JSON.
4. What is the purpose of metadata in an IoT system?
5. Explain the difference between event time and ingestion time.

Long Answer Questions

1. Compare JSON, XML and CBOR for an IoT deployment involving constrained sensors and enterprise applications.
2. Explain how schemas, controlled vocabularies and ontologies work together to support interoperability.
3. Describe a suitable API and data contract for device registration, telemetry and alarm management.
4. Discuss schema evolution and backward compatibility in a multi-vendor IoT platform.
5. Explain the security, privacy and governance issues that arise when IoT data is shared across organisations.

Analytical / Application Questions

1. A sensor reports temp: 77 but does not identify a unit, timestamp standard or location. Identify the interoperability risks and propose a corrected data model.
2. Four systems must exchange observations. Compare a point-to-point integration strategy with a canonical model, including the conceptual mapping effort and likely governance risks.
3. Design a transformation pipeline for a cold-storage system in which one vendor sends Fahrenheit JSON, another sends Celsius CBOR, and the enterprise maintenance system requires XML. Identify the required validation, metadata, semantic mapping and security controls.

Multiple Choice Questions with Answers

Question 1

Which type of interoperability concerns whether two systems assign the same meaning to a field?

A. Physical interoperability

B. Semantic interoperability

C. Transport interoperability

D. Electrical interoperability

Correct Answer: B. Semantic interoperability

Question 2

Which format is a compact binary representation particularly suitable for constrained IoT devices?

A. HTML

B. XML

C. CBOR

D. CSV

Correct Answer: C. CBOR

Question 3

What does the suffix Z commonly indicate in an ISO 8601 timestamp?

A. Local time

B. Daylight-saving time

C. Coordinated Universal Time

D. Unknown time zone

Correct Answer: C. Coordinated Universal Time

Question 4

Which item is metadata?

A. A sensor reading of 23.6 °C

B. The sensor calibration date and measurement range

C. An MQTT packet acknowledgement

D. A device power cable

Correct Answer: B. The sensor calibration date and measurement range

Question 5

What is the principal purpose of a schema?

A. To encrypt every message

B. To define permitted structure, types and constraints

C. To replace all network protocols

D. To physically calibrate a sensor

Correct Answer: B. To define permitted structure, types and constraints

Question 6

A sensor reports 41 °F. What is the equivalent temperature in Celsius?

A. −5 °C

B. 0 °C

C. 5 °C

D. 41 °C

Correct Answer: C. 5 °C

Question 7

Which statement best describes an ontology in IoT?

A. A physical sensor wiring diagram

B. A formal specification of domain concepts and relationships

C. A binary compression algorithm

D. A network cable standard

Correct Answer: B. A formal specification of domain concepts and relationships

Question 8

What is provenance used to describe?

A. The origin and transformation history of data

B. The maximum battery voltage only

C. The colour of a device enclosure

D. The number of API endpoints

Correct Answer: A. The origin and transformation history of data

Question 9

In a canonical integration model, each external system generally maps to what?

A. Every other external system directly

B. A shared internal representation

C. Only the physical network layer

D. A different unit system with no conversion

Correct Answer: B. A shared internal representation

Question 10

Which practice best supports backward-compatible schema evolution?

A. Changing the meaning of an existing field silently

B. Removing required fields without notice

C. Adding optional fields and documenting versions

D. Ignoring validation after deployment

Correct Answer: C. Adding optional fields and documenting versions