Edit this page

Ditto’s data model organizes IoT device data into a hierarchy of Things, Features, and Policies.

TL;DR: A Thing has attributes (static metadata) and features (dynamic state). A Policy controls who can read and write each part. That is the entire data model.

How the model works

Ditto does not enforce a specific schema for your IoT data. Instead, it provides two structural elements inside each Thing:

  • Attributes – static metadata about the Thing (location, serial number, manufacturer) stored as a JSON object. These values do not change frequently.
  • Features – dynamic state data (sensor readings, configuration, operational status). Each Feature groups related properties under a named identifier.

Access control is managed separately through Policies. The Thing references its Policy by policyId, and that Policy defines which authenticated subjects may read or write the Thing or parts of it.

Ditto Class Diagram
Class diagram of Ditto's core entities.

Minimal Thing

The smallest valid Thing contains only an ID and a reference to its Policy:

{
  "thingId": "the.namespace:the-thing-id",
  "policyId": "the.namespace:the-policy-id"
}

Attributes and Features are optional.

A Thing with data

A more realistic Thing includes a definition, an attribute, and a feature:

{
  "thingId": "the.namespace:the-thing-id",
  "policyId": "the.namespace:the-policy-id",
  "definition": "digitaltwin:DigitaltwinExample:1.0.0",
  "attributes": {
    "location": "Kitchen"
  },
  "features": {
    "transmission": {
      "properties": {
        "cur_speed": 90
      }
    }
  }
}

Further reading

  • Things – full details on Thing structure, IDs, and attributes
  • Features – properties, desired properties, and definitions
  • Policies – fine-grained access control for Things and Features
  • Namespaces & Names – naming conventions for entity IDs
Tags: model