W3C Web of Things (WoT) Reference Architecture for Industrial IoT

Walk any brownfield plant floor and you will find the same archaeology: a 1990s PLC speaking Modbus RTU over RS-485, a 2010-era energy meter on Modbus TCP, a fleet of newer CoAP sensors, an OPC UA server fronting the SCADA historian, and an MQTT broker that a systems integrator bolted on last year. Each device is reachable. None of them describe themselves the same way, and no two integrate the same way. The web of things architecture does not try to rip any of this out. It places a thin, machine-readable description layer on top so that a single client can discover, understand, and operate all of them through one uniform interaction model. That is the entire bet of the W3C Web of Things: standardize the description of a device, not the wire protocol underneath it.

This matters now because the number of protocols is still growing — Matter, MQTT Sparkplug, OPC UA over MQTT — and every new one adds another integration silo. WoT is the W3C’s answer: a metadata layer that turns heterogeneity from a per-device engineering problem into a parsing problem.

What this covers: the four WoT building blocks, the Thing Description information model, protocol bindings across HTTP/CoAP/MQTT/Modbus/OPC UA, the architectural roles, semantic interoperability, deployment patterns, and where it breaks.

Context and Background

IoT interoperability has a long graveyard of attempts. The field-bus wars of the 1990s gave us Modbus, PROFIBUS, EtherNet/IP, and a dozen others, each optimized for a vendor ecosystem. The 2000s standardized transports — REST over HTTP, then CoAP for constrained devices (RFC 7252), then MQTT for pub/sub telemetry. The 2010s layered information models on top: OPC UA brought a rich address space and companion specifications; Sparkplug B brought structured, stateful MQTT payloads; oneM2M defined a horizontal service layer. Each solved interoperability within its own ecosystem and created a new boundary at its edge.

The result is a familiar pathology. A consumer that already speaks OPC UA still cannot talk to a CoAP sensor without bespoke glue code, because the two ecosystems disagree not only on transport but on how a device advertises what it can do. The integration cost is quadratic: N protocols and M client platforms imply roughly N×M adapters, and every adapter encodes tribal knowledge about register maps, topic structures, and payload schemas that lives only in an engineer’s head or a spreadsheet.

The W3C chartered the Web of Things Working Group to attack this from a different angle. Instead of proposing protocol N+1, WoT defines a description format and an interaction abstraction that sit above whatever protocol a device already uses. The two normative pillars are the W3C WoT Architecture 1.1 and the W3C WoT Thing Description 1.1 Recommendations, both published as W3C Recommendations. The philosophy aligns closely with the broader move toward a single, governed data backbone on the plant floor — see our deep dive on unified namespace architecture for industrial IoT, which WoT complements rather than competes with.

It is worth being precise about why earlier horizontal-interoperability projects under-delivered, because WoT’s scope was chosen explicitly to avoid their traps. oneM2M defined a comprehensive service layer but required wholesale adoption of its resource model and its mca/mcc reference points; you bought in fully or not at all. The Open Connectivity Foundation (OCF) similarly specified its own transport and resource model. Both efforts asked the ecosystem to converge on a new common stack — and ecosystems resist converging on new stacks, because every existing deployment becomes legacy the day the standard ships. WoT inverts the imposition. It assumes the protocols already on the floor are permanent and merely asks each device (or a proxy in front of it) to publish a description in a single agreed format. The migration cost is therefore additive, not destructive: you write a TD, you do not replace a bus. That single architectural decision — describe, do not displace — is the reason WoT has been adoptable in brownfield industrial settings where every prior horizontal standard stalled.

The Web of Things Reference Architecture

The Web of Things reference architecture is an abstraction layer, not a protocol. It models every device as a Thing described by a JSON-LD Thing Description (TD) that declares the Thing’s properties, actions, and events plus the concrete network endpoints (forms) and security schemes needed to use them. A Consumer parses the TD; a Servient can host or consume Things; a Thing Directory indexes TDs for discovery. The protocol stays whatever it already is.

Figure 1: The layered WoT reference architecture. Applications drive a Consumer layer that discovers Thing Descriptions via a Thing Directory; the Servient runtime maps the TD’s abstract affordances to concrete protocol bindings, which reach physical devices over HTTP, CoAP, MQTT, Modbus, or OPC UA.

The crucial design move is the separation of the interaction model from the protocol binding. The interaction model is abstract and stable: a Thing exposes properties (state you can read or write), actions (operations you invoke), and events (asynchronous notifications you subscribe to). The protocol binding is concrete and per-Thing: it says that reading the temperature property means issuing an HTTP GET to a specific URL, or that invoking the reset action means writing a value to Modbus holding register 40012. A Consumer reasons in terms of the abstract model and the TD tells it, declaratively, how to execute each interaction on the wire. No code generation, no compiled stubs — the contract is data.

It is worth dwelling on why the three affordance types — properties, actions, events — are the right primitives rather than an arbitrary choice. They map cleanly onto the three fundamentally different temporal semantics a device interaction can have. A property is state with a current value: reads are idempotent, writes set a value, and the question “what is it now” always has an answer. An action is a process that takes time and may have side effects: invoking it is not idempotent, it can accept input and return output, and it models things like “run a calibration cycle” or “move to position” where the request initiates work rather than reading or setting a value. An event is a discrete occurrence the Thing emits on its own schedule: an alarm, a threshold crossing, a state transition the Consumer wants to know about without polling. Almost every real device interaction collapses into one of these three, and pinning each to its natural protocol mechanism — properties to GET/PUT or retained topics, actions to POST or command sequences, events to push channels — is what keeps the bindings honest. When an engineer is tempted to model a long-running operation as a writable property, the affordance taxonomy is what tells them they have chosen the wrong primitive and will fight the protocol mapping forever.

Thing Description anatomy

The Thing Description is the heart of WoT, and everything else orbits it. A TD is a JSON-LD 1.1 document, which means it is valid JSON and carries a @context that maps its terms to a shared semantic vocabulary. The root object carries identity (id, title, description), the @context array, a securityDefinitions block, a top-level security array naming which schemes apply by default, and three affordance maps: properties, actions, and events.

Each affordance contains a data-schema description (drawn from a JSON Schema vocabulary — type, minimum, maximum, unit, enum) and, critically, a forms array. A form is the binding: it has an href (the endpoint), a contentType (default application/json), and an op array naming which abstract operations the form supports — readproperty, writeproperty, observeproperty, invokeaction, subscribeevent, and so on. Forms can also carry protocol-specific terms via vocabulary extensions, such as an MQTT topic, a CoAP method, or a Modbus function code and register address. This is what makes a single TD able to span transports: each affordance can have multiple forms, each pointing at a different protocol.

A worked example sharpens the point. Suppose a heat exchanger exposes an inletTemperature property. In the TD it appears under properties with a data schema of { "type": "number", "unit": "Cel", "minimum": -40, "maximum": 200, "readOnly": true } and a single form whose op is ["readproperty", "observeproperty"], whose href is coap://10.4.2.7/temp, and which sets cov:method to GET and declares the CoAP Observe option for the observe operation. A Consumer that has never seen this device reads exactly those fields and now knows the value is a Celsius temperature bounded at 200, that it can be read or observed, that the transport is CoAP, and that observation is push-based and cheap. No documentation, no integration meeting. If the same exchanger were also surfaced through an edge gateway, the gateway’s re-exposed TD would carry a second form on the same property — https://gw.plant.local/hx7/inletTemperature with an SSE subprotocol — and the Consumer picks whichever form matches the protocols it speaks. The two forms describe one logical property reachable two ways; the affordance, units, and bounds are stated once and inherited by both.

The TD also distinguishes the interaction-affordance level from the data-schema level deliberately. The affordance answers “what can I do” (read, write, observe, invoke, subscribe); the data schema answers “what shape is the payload” (number, object with named fields, array, the units, the constraints). Keeping these orthogonal is what lets a single Consumer generate a generic UI or a generic mapping into a historian: it can render any property’s editor from its data schema and wire up any action’s invoke button from its affordance, regardless of the device behind it.

The four building blocks

WoT is defined as four loosely coupled building blocks, and a conformant deployment can adopt any subset. Thing Description is the only mandatory one — it is the lingua franca. Binding Templates are non-normative guidance documents that show how to express forms for a given protocol (HTTP, CoAP, MQTT, Modbus, OPC UA); they keep TDs interoperable by standardizing how, say, a Modbus register is encoded in a form. The Scripting API is an optional, ECMAScript-based runtime API (think consumeThing(td) returning an object whose methods mirror the affordances) that lets developers produce and consume Things in JavaScript without hand-rolling protocol code; node-wot is the reference implementation. Discovery defines how Consumers find TDs — through a directory service (the Thing Directory, exposing a queryable HTTP API), through direct exchange, or through self-description at a well-known URL (/.well-known/wot).

The Thing Directory deserves a closer look because it is where WoT becomes operationally interesting at fleet scale. It is specified as a service with a small HTTP API: Things (or the servients fronting them) register their TDs, and Consumers query by criteria — type, semantic annotation, geographic or topological location. The directory typically stores TDs in a form amenable to SPARQL or JSON-path querying, so a Consumer can ask “give me every Thing whose @type is a temperature sensor on Line 3″ and receive a set of TDs to act on, with no prior knowledge of how many devices exist or where they live. This is the mechanism that turns a static integration into a dynamic one: add a conformant sensor, have it register, and Consumers that query by type pick it up without redeployment. The discovery spec deliberately separates an introduction phase (how you learn a directory or Thing exists — DNS-SD, a well-known URI, a QR code, a beacon) from an exploration phase (fetching the actual TD), and it puts access control on exploration precisely because the TD reveals so much. That two-phase split is a security feature, not bureaucracy: introduction can be open while exploration stays authenticated.

Servients, Consumers, and roles

WoT defines behavioral roles, not boxes. A Thing is any entity exposing a TD. A Consumer is software that fetches and acts on a TD. A Servient is a software stack that can play either or both roles — it can expose Things (acting as a server, hosting their TDs and handling incoming requests) and consume Things (acting as a client to other Things). The servient is the workhorse of real deployments: an edge gateway servient consumes legacy Modbus and OPC UA Things on the southbound side and re-exposes them as clean HTTP/CoAP WoT Things northbound, becoming an Intermediary. Because a TD describes a Thing regardless of who serves it, an intermediary can proxy, aggregate, or transform Things transparently, and Consumers cannot tell whether they are talking to the device or a gateway in front of it.

This role decomposition is what makes WoT compositional rather than point-to-point. An intermediary servient can do more than relay: it can aggregate several southbound Things into one synthetic Thing (a TD for “Line 3” whose properties fan out to a dozen physical sensors), it can transform affordances (clamp, scale, or unit-convert a raw register into engineering units before re-exposing it), and it can cache slow southbound reads so a chatty cloud Consumer never hammers a 9600-baud serial bus directly. Each of these is just another servient that consumes one TD and exposes another. Because the abstraction is uniform at every hop, you can chain them — device servient, edge aggregating servient, cloud-facing security-terminating servient — and the topmost Consumer still sees nothing but Things and TDs. The Architecture 1.1 Recommendation also defines a digital-twin deployment variant where the exposed Thing lives in the cloud and mirrors a physical device that may be intermittently connected; the TD is identical, but the servient buffers commands and reconciles state on reconnect, which is how WoT participates in classic digital-twin patterns without a separate twin protocol.

Protocol Bindings and Semantic Interoperability

A protocol binding is the rule set that maps an abstract WoT operation onto a concrete protocol exchange. The TD carries the binding inline, per form, so the same interaction model lands on radically different wires. Figure 2 shows how the interaction model decomposes into affordances, forms, and security schemes; Figure 3 traces a full consume-discover-invoke flow through a servient.

Figure 2: The Thing Description interaction model. The TD root branches into properties, actions, and events; each affordance owns one or more forms that pin an operation to a transport endpoint, optionally qualified by a subprotocol such as long-poll or server-sent events, and governed by the TD’s security schemes.

Consider the same temperature property across protocols. Over HTTP, the form’s href is an absolute URL and readproperty maps to GET, writeproperty to PUT, and observeproperty to either long-polling or server-sent events declared via a subprotocol term. Over CoAP, the same operations map to GET and PUT methods but use CoAP’s native Observe option (RFC 7641) for observeproperty, which is far cheaper on the wire for constrained nodes. Over MQTT, there is no request/response — readproperty is expressed as a subscription to a retained topic, writeproperty as a publish to a command topic, and observeproperty as an ordinary subscription. Over Modbus, the form carries the function code (read holding registers, write single register) and the register address, plus byte-order and data-type hints, because Modbus has no self-description at all.

Affordance / Operation	HTTP	CoAP	MQTT	Modbus
readproperty	GET on href	GET method	subscribe to retained topic	read holding/input registers (FC 3/4)
writeproperty	PUT on href	PUT method	publish to command topic	write register(s) (FC 6/16)
observeproperty	SSE or long-poll subprotocol	Observe option (RFC 7641)	subscribe to topic	poll loop (no native push)
invokeaction	POST with body	POST method	publish to action topic	write register sequence
subscribeevent	SSE / WebSocket	Observe on event resource	subscribe to event topic	poll status register
Security default	bearer / basic / oauth2	psk (DTLS)	basic / psk over TLS	none (network-segmented)

The table makes the cost of heterogeneity visible. Modbus has no push, so observeproperty and subscribeevent degrade to a servient-side poll loop — the binding hides this from the Consumer but the latency and bus-load characteristics are very different. MQTT inverts the request/response assumption entirely, so a naive Consumer expecting a synchronous read must rely on retained messages or a request/response convention layered on top. These are not WoT defects; they are honest reflections of what each protocol can and cannot do, surfaced in the TD instead of buried in adapter code.

Put numbers on it. A CoAP Observe notification rides in a single UDP datagram — the CoAP header is 4 bytes plus token and a few options, so a temperature update can leave the device in well under 50 bytes with no connection setup. The same logical “tell me when temperature changes” over HTTP long-polling costs a full request/response round trip per poll interval, each carrying hundreds of bytes of headers, plus a TCP (and likely TLS) handshake amortized across the connection’s lifetime; over server-sent events you pay the TCP/TLS setup once but hold the connection open. For a battery- or bandwidth-constrained node the difference between CoAP Observe and HTTP polling is often an order of magnitude in bytes-on-air and a corresponding hit to battery life. Meanwhile the Modbus poll loop carries a different cost entirely: a single-register read is two PDU bytes of request and a few bytes of response, but because there is no push, the servient must poll continuously, and a 9600-baud RS-485 RTU segment shared across twenty slaves can only sustain a handful of complete read cycles per second. That ceiling — not WoT — is what bounds your effective sample rate, and the TD makes it explicit by forcing you to declare the binding rather than pretend the device pushes when it cannot.

There is also a subtle correctness trap in the MQTT mapping. Because readproperty over MQTT is implemented as “subscribe and wait for a retained message,” a Consumer’s first read returns whatever value was last published — which may be minutes stale if the device only publishes on change. A servient that wants true read-on-demand semantics over MQTT has to layer a request/response convention (publish to a …/get topic, await a reply on a correlated topic) on top of the broker. WoT lets you declare that convention in the form via subprotocol terms, but it cannot conjure synchronous semantics from a fundamentally asynchronous fabric. Recognizing where the abstraction is leaky — and choosing the right protocol for each affordance’s real-time needs — is exactly the judgment the TD is meant to make visible rather than hide.

Semantic interoperability is the second half of the story, and it is where WoT earns its keep beyond mere connectivity. Two devices can both expose a temperature property and still be incompatible if one means degrees Celsius at the inlet and the other means Fahrenheit at the exhaust. The TD’s @context and JSON-LD typing let you attach machine-readable meaning. By adding an ontology to the @context and tagging an affordance with @type: "saref:Temperature" (from the ETSI SAREF ontology) or a domain-specific term, a Consumer — or a reasoning engine — can interpret the property without a human in the loop. This is what separates WoT from a glorified API catalog: the descriptions are not just structural, they are semantic, and they can be validated, queried with SPARQL, and reasoned over. The Asset Administration Shell community is converging on similar JSON-LD-grounded semantics; see our Asset Administration Shell (AAS) reference architecture for the Industrie 4.0 counterpart.

Figure 3: A consume-discover-invoke sequence. The Consumer queries the Thing Directory by type, parses the returned TD’s forms and security, then invokes an action; the servient selects the appropriate binding (here a Modbus register write) and later relays an event back over server-sent events.

In practice the servient is where bindings get resolved. When a Consumer calls an action through the Scripting API, the servient inspects the form, picks the matching protocol client, executes the exchange, applies the declared security scheme, and maps the result back into the abstract output schema. For high-throughput pub/sub fabrics the same TD can point at an MQTT broker, which is exactly how WoT layers cleanly onto a unified namespace or onto real-time data buses like DDS (Data Distribution Service) without forcing a rewrite of the underlying transport.

Security is itself part of the binding, not an afterthought bolted on later. The TD’s securityDefinitions block names one or more schemes — nosec, basic, digest, bearer, psk, apikey, oauth2 — and the top-level security array, or a per-form override, says which apply where. The scheme definition is declarative and complete enough for a Consumer to act on: a bearer scheme states where the token goes (in: header, name: Authorization), its format, and the authorization-server URL; an oauth2 scheme names the flow, token, and scopes. This means provisioning credentials and discovering how to authenticate are two different problems — the TD answers “how do I authenticate” but never carries the secret itself. A Consumer reads the scheme, fetches or already holds the matching credential from its own secret store, and applies it per the declaration. The practical consequence for industrial deployments is that the choice of security scheme is bound to the protocol’s realistic capabilities: CoAP nodes typically declare psk backed by DTLS, HTTP services declare bearer or oauth2, and bare Modbus declares nosec because the protocol has no authentication at all — which is precisely why a Modbus segment must be isolated behind the servient and never directly exposed.

Trade-offs, Gotchas, and What Goes Wrong

WoT is a description layer, and description layers fail in description-layer ways. Figure 4 shows a realistic edge deployment that concentrates most of these risks in one node.

Figure 4: An edge servient gateway terminates OPC UA, CoAP, Modbus TCP, and legacy serial RTU traffic, hosts the Thing Directory, and re-exposes everything northbound through an MQTT unified namespace to a cloud consumer and digital twin.

The first and largest cost is TD authoring burden. Someone must write an accurate Thing Description for every legacy device — its register map, its units, its security scheme — and Modbus and proprietary buses give you nothing to auto-generate from. Get a register address or byte order wrong and the binding is silently incorrect; the Consumer reads a plausible-looking but meaningless number. TDs should be version-controlled, schema-validated against the official TD JSON Schema, and treated as production config, not documentation.

The second is discovery security. A Thing Directory that anyone can query is a reconnaissance gift to an attacker — it enumerates every device, endpoint, and security scheme on the network in a single, well-structured response. The WoT Discovery specification addresses this with a two-phase introduction-then-exploration flow and mandates authentication on directory queries, but a careless deployment that exposes an open directory has effectively published its attack surface. Treat the directory as privileged infrastructure.

Third, overhead and versioning. A rich TD with full semantic annotation can run to tens of kilobytes, which is non-trivial to ship to a constrained CoAP node; the common pattern is to host the TD off-device and keep only a thin self-link on the device. And TDs evolve — a firmware update that adds a property changes the TD, so directories and Consumers need a cache-invalidation and version story or they will act on stale contracts. Finally, WoT adds an indirection: it does not make a slow Modbus poll fast, and the servient hop adds latency. WoT buys uniformity and discoverability, not performance.

A fourth, quieter failure mode is semantic drift. The whole value proposition rests on @context annotations meaning the same thing across vendors, but nothing forces an author to use a shared ontology — a TD with no semantic types is still perfectly valid, just structurally interoperable rather than semantically interoperable. In practice many TDs in the wild annotate units inconsistently or invent local terms, so two Consumers can parse the same TD and still disagree about meaning. Catching this requires governance, not tooling: a curated ontology list, lint rules in CI that reject unrecognized @type values, and review of TDs the way you review API contracts. A related trap is the single-point-of-failure that the servient and directory become. Concentrating every binding into one edge gateway (Figure 4) is operationally convenient and a blast-radius liability — if that node dies, every northbound Consumer loses every southbound Thing at once. Mitigations are conventional (redundant servients, a replicated or clustered directory, health-checked failover) but they have to be designed in, because the uniform abstraction tempts you toward a tidy single chokepoint that you would never have built with point-to-point integrations.

Practical Recommendations

Adopt WoT as a façade over what you have, not a forklift replacement. Stand up an edge servient gateway first, point it at your highest-value legacy assets, and let it re-expose them as clean WoT Things northbound while leaving the southbound protocols untouched. Use node-wot or another reference servient before building your own — the Scripting API will save you from hand-coding five protocol clients. Keep Thing Descriptions in source control next to your infrastructure-as-code, validate them in CI against the official TD schema, and attach semantic types (SAREF, QUDT for units, or your own ontology) from day one rather than retrofitting meaning later. Layer WoT over your unified namespace or MQTT fabric so the same TD can address both request/response and pub/sub consumers.

Sequence the rollout so value lands before risk accumulates. Phase one is a read-only pilot: pick one cell or line, write TDs for its highest-value sensors and meters, and prove that a single Consumer can discover and read all of them through one model — no writes, no actions, minimal blast radius. Phase two adds actuation (actions, writable properties) only once the security model is real: authenticated directory, per-form security schemes, and the Modbus segment firewalled behind the servient. Phase three federates — multiple servients, a replicated directory, and northbound exposure to cloud analytics and the digital twin. Treat the Thing Directory as tier-one infrastructure from phase two onward: it is both your discovery backbone and your most sensitive inventory, so it gets authentication, audit logging, and the same uptime SLO as the historian it feeds. Capacity-plan the southbound buses explicitly — compute the worst-case poll rate the servient will generate against each serial segment and confirm it fits the baud-limited cycle budget before you promise a sample rate to the analytics team. Most “WoT is slow” complaints are really “we oversubscribed a 9600-baud RS-485 segment” complaints, and the TD’s explicit binding is what lets you catch that on paper instead of in production.

Pre-deployment checklist:

Every TD validates against the W3C TD 1.1 JSON Schema in CI.
Units and data types are semantically typed (@type, unit), not free text.
Forms declare explicit op, contentType, and security per affordance.
Modbus/proprietary bindings have verified register maps and byte order.
Thing Directory requires authentication; introduction phase is access-controlled.
TDs are version-stamped with a cache-invalidation strategy for firmware changes.
A servient owns the poll-to-push translation for protocols without native push.

Frequently Asked Questions

What is a Thing Description?

A Thing Description (TD) is the W3C WoT’s machine-readable document describing a single device or service. It is a JSON-LD 1.1 file with a @context for semantics, an identity block, security definitions, and three affordance maps — properties, actions, and events. Each affordance carries a data schema and one or more forms that pin its abstract operations to concrete network endpoints (a URL, a CoAP method, an MQTT topic, a Modbus register). The TD is the only mandatory WoT building block: it is the contract a Consumer parses to discover, understand, and operate the Thing without any device-specific code.

Is WoT a protocol?

No. This is the most common misunderstanding. WoT is deliberately not a new transport or messaging protocol — it adds no bytes to the wire that a device sends. It is an abstraction and metadata layer that describes how to use whatever protocol a device already speaks. A WoT deployment runs over HTTP, CoAP, MQTT, Modbus, OPC UA, or any mix of them; the Thing Description tells a Consumer which protocol each interaction uses and how. WoT standardizes the description and the interaction model, not the communication protocol underneath.

How does WoT compare to OPC UA?

They operate at different layers and are complementary, not rivals. OPC UA is a full stack — transport, a rich typed address space, companion information models, and security — optimized for industrial automation and excellent within its ecosystem. WoT is a thin description layer that sits above protocols, including OPC UA itself: a TD can declare an OPC UA binding, letting a WoT Consumer treat an OPC UA server as one Thing among many alongside CoAP and MQTT devices. Use OPC UA for deep, typed plant-floor modeling; use WoT to give heterogeneous devices — OPC UA included — one uniform, web-friendly description and discovery surface.

What are WoT protocol bindings?

A protocol binding is the mapping from WoT’s abstract operations (readproperty, invokeaction, subscribeevent) onto a concrete protocol’s mechanics. The binding lives inside the TD’s forms: each form names the operations it supports plus protocol-specific details — an HTTP method, a CoAP Observe option, an MQTT topic, a Modbus function code and register. The W3C publishes non-normative Binding Templates that standardize how to express these per protocol, so a TD authored for Modbus by one vendor is readable by any conformant Consumer. Bindings are what let one interaction model span request/response, observe/notify, and pub/sub transports.

Do I need a Thing Directory to use WoT?

No — discovery is an optional building block. You can hand a Consumer a TD directly, fetch it from a device’s /.well-known/wot self-description endpoint, or pull it from a file or registry. A Thing Directory becomes valuable at scale: it is a queryable service (an HTTP API, often SPARQL-backed) where Things register their TDs and Consumers search by type, location, or capability. For a handful of devices, direct TD exchange is simpler; for fleets, a directory provides dynamic discovery — at the cost of becoming privileged, access-controlled infrastructure that must not leak your device inventory.

Can WoT and Matter or Sparkplug coexist?

Yes, and that is the intended posture. WoT layers over existing ecosystems rather than competing with them. A Matter device or an MQTT Sparkplug B node can be wrapped by a servient that publishes a Thing Description binding to the underlying Matter cluster or Sparkplug topic namespace. The Consumer then interacts through the uniform WoT model while the native protocol keeps running beneath. This is exactly the gateway/intermediary pattern: WoT becomes the common description and discovery surface across Matter, Sparkplug, OPC UA, and raw Modbus, without any of them having to change.

W3C Web of Things (WoT) Reference Architecture for Industrial IoT (2026)