An ontology is a formal specification of the concepts, properties, relationships, and rules in a domain. In a digital twin, it gives sensor readings and asset records a shared meaning: a temperature value can be understood as a measurement from a particular sensor in a particular room, rather than just a number. It is a blueprint for interpreting data, not the data store itself. section 5.3 section 5.3.1 section 5.6.3
Define the domain in four parts:
- Classes name types of things, such as Machine, Product, and Building. section 5.3.1
- Properties describe instances, such as a machine’s operationalStatus. section 5.3.1
- Relationships connect concepts, such as a Product being processedBy a Machine. section 5.3.1
- Rules constrain valid states; for example, an offline Machine cannot process a Product. section 5.3.1
A knowledge graph can put this blueprint to work: its nodes represent entities, while semantically named edges represent their relationships. A hasLocation edge between a sensor and a room states what the connection means. Labeled property graphs and RDF are two ways to represent such connected data; OWL supplies constructs for defining ontologies over RDF. A GraphQL schema can also encode an ontology as a query contract, with its type system enforcing that model at runtime. section 5.4 section 5.4.1 section 5.4.2 section 5.6.3
Listing 5.2 A minimal example of how a room might be defined using DTDL
{
"@id": "dtmi:com:dtia:Room;1", #1
"@type": "Interface", #2
"displayName": "Room",
"contents": [
{
"@type": "Property",
"name": "occupancyStatus",
"displayName": "Occupancy Status",
"schema": "boolean"
},
{
"@type": "Telemetry",
"name": "temperature",
"displayName": "Temperature",
"schema": "double"
}
],
"@context": "dtmi:dtdl:context;3" #3
}
A minimal DTDL Room interface makes the distinction concrete: occupancyStatus is a property, while temperature is telemetry. The definition specifies what a room twin can contain; it does not supply a room’s readings. section 5.3.2
Choose an existing ontology when its vocabulary fits: it improves interoperability and may have tool support, but its definitions can be restrictive. Extend one when necessary, accepting the work of maintaining extensions and potentially reduced compatibility. A custom ontology can fit precisely but sacrifices a shared vocabulary. At industrial scale, govern changes across disciplines and reconcile conflicting models; a wrongly classified graph relationship can affect every query that follows it. section 5.3.3 section 5.5.4
