A schema specifies what data a system exposes and how its parts relate. In a GraphQL API, it is a contract for available queries. For a digital twin, it also models the physical system: spaces contain sensors, and measurements gain meaning from the spaces and sensors they describe. A schema based on the RealEstateCore ontology uses a shared vocabulary rather than an isolated custom model. section 5.6.3
Listing 5.5 GraphQL query schema for a home twin
type Query { #1
spaces(space: String!, start_date: String!,
end_date: String!): [Space!]!
}
type Space { #2
name: String!
sensors: [Sensor!]!
documents: [Document!]!
images: [Image!]!
measurements: [MeasurementGroup!]!
}
type Sensor {
id: String!
space: String!
}
type Document {
id: String!
url: String!
}
type Image {
id: String!
url: String!
}
type MeasurementGroup {
name: String!
unit: String
values: [Measurement!]!
}
type Measurement {
sensor_id: String!
timestamp: String!
value: Float!
}
The home-twin query schema makes those relationships concrete. A query requests spaces within a date range; each space exposes sensors, documents, images, and grouped measurements. Required fields and lists state what clients can expect. section 5.6.3
One query over multiple sources
A smaller weather API exposes a `weather(city)` query. Its resolver first obtains the city’s coordinates from a geocoding API, then requests forecast data from Open-Meteo. The client asks for time, rain, and surface temperature through one GraphQL query rather than coordinating both calls. section 5.6.3
A production schema must evolve without surprising its consumers:
- Prefer additive fields. Adding `power_kw` can preserve existing consumers; renaming `temperature` to `temp_c` can silently break them. section 10.3.3
- Keep telemetry ingestion, state storage, analytics, and actuation loosely coupled so a new sensor field does not force every downstream consumer to be redeployed. section 10.3.3
- Reassess schema choices at industrial data volumes: decisions that work for thousands of daily readings may perform poorly at millions. section 4.5.4
