# Digital Twin and Internet of Things--Current Standards Landscape
## 4 Summary
Their idea is that there are already plenty of IoT devices and systems deployed and changing/updating their interfaces is not an option. Therefore, the WoT approach is to provide a way to describe existing resources and their APIs. Although WoT is the only standard following this approach, it seems like a valid claim considering there are already trillions of IoT devices deployed, often without the possibility to update them over-the-air. For resource access protocols, HTTP seems to be general consent. Typically, it is \begin{table}
\begin{tabular}{l l l l l l l} \hline \hline Resource Description & **AAS** & **DTDL** & **NCSI-LD** & **OData** & **STA** & **WoT** \\ \hline Resource Term & Asset & Interface & Entity & Entity & Thing & Thing \\ Model Type(s) & Meta & Meta & Meta & Meta & Cross-Domain & Meta \\ Resource Identification & IRI & DTMI & URI & URL & URL & URL & URI \\  & IRDI & & custom & & custom & & custom \\ Type System (based on) & XSD & custom & JSON & custom & JSON & JSON & JSON \\  & & & GeoJSON & & & SWE-standards & JSON Schema \\  & & & JSON+LD & & X & -* & X \\ Resource Interlinking & X & X & X & X & - & O* & X \\ Semantic Annotation & X & O* & X & - & O* & X \\ Resource Elements & & & & Cross-Domain & X & X & X \\ Properties & X & X & X & X & X & X \\ Services & X & X & - & O* & O & X \\ Events & X & X & X & O* & - & O* & X \\ Serialization Format & JSON & JSON & JSON & JSON & JSON & JSON & JSON \\  & RDF & RDF & RDF & XML & & RDF \\ XML & XML & Avro & & & & RDF \\  & OPC UA & & Protobuf & & & & \\  & \multicolumn{2}{l}{AutomationML} & & & & & \\ Supported Kind of Data & & & & & & \\ geo-spatial & - & - & X & X & X & - \\ temporal & - & - & X & X & X & - \\ historical & - & - & X & - & O* & - \\ \hline Resource Discovery & & & & & & \\ Protocols & -* & - & HTTP & HTTP & HTTP & HTTP & HTTP \\  & & & & & & CoAP* \\  & & & & & & DN*SD * \\ Querying supported? & -* & - & X & X & X & O* \\ Query Language & & - & custom & custom & OData & SPARQL* \\ Query Language based on & - & - & X & X & X & - \\ geo-spatial queries & - & - & X & - & O* & - \\ historical queries & - & - & X & - & O* & - \\ \hline Resource Access & & & & & & \\ API: Define vs. Describe & define & - & define & define & describe \\ Protocols & HTTP & - & HTTP & HTTP & HTTP & HTTP \\  & MQTT & & & & MQTT & MQTT \\  & & & & & CoAP \\ Protocols extendible? & & - & X & - & - & X \\ \hline \hline \end{tabular}  
\end{table} 
Table 1: Comparison of the following internet of things and digital twin standards: AssetAdministrationShell (AAS), Digital Twin Definition Language (DTDL) v2.0, Next Generation Service Interfaces—Linked Data API (NCSI-LD API), Open Data Protocol (OData) v4.0, SensorThings API (STA) v1.0, and Web of Things (WoT). accompanied by MQTT adding pub/sub functionality that HTTP is missing. Not limiting itself to a specific set of communication protocols seems like a good idea, as APIs should, in general, be protocol agnostic and also because the past shows that almost every communication protocol evolves over time and will eventually be replaced. In general, it is to notice, that besides IoT and DT being broad domains with heterogeneous applications and partially different requirements, there exists some shared common core functionality of resource description, discovery and access. Different standards, developed by different SDOs, having different backgrounds like, e.g., environmental measurements, industrial production, appliances, or consumer electronics, came up with partially very similar standards, showing that there might be a chance for even better convergence. Furthermore, there is a need to abstract from the underlying technologies when mapping requirements on resource management and their DT counterparts systematically to capabilities of underlying IoT infrastructures [62]. DT Engineering will become a crucial methodology in future IoT environments.