# Digital Twin and Internet of Things--Current Standards Landscape
## 3 Standards for Digital Twins and the Internet of Things
### Next Generation Service Interfaces-Linked Data API  
The Next Generation Service Interfaces-Linked Data (NGSI-LD) API [43] is an IoT standard defined by the ETSI Industry Specification Group (ISG) crosscutting Context Information Management (CIM). I is based on the Open Mobile Alliance (OMA) NGSI 9 and 10 interfaces [44] and FIWARE NGSlv2 [45]. In this paper, we refer to version 1.2.2 released 02/2020 [43]. Although never mentioning the term DT, the standard revolves around so-called 'Entities represent[ing] physical or conceptual objects existing in the real world' [46], which is more or less the definition of DT. In contrast to other standards, resources (entities) in NGSI-LD only comprise properties and relations to other resources. Services and events are not supported, although events can be partially realized through subscribing to property changes, which is supported.  
As shown in Figure 5, NGSI-LD does not only provide a meta model defining general concepts such as Entity, Relationship and Property, but also a cross-domain ontology defining essential temporal and geo-spatial terms and concepts. Besides explicitly providing temporal and geo-spatial terms and concepts, the standard further supports historical data by allowing querying the state of an entity at any time in the past. Although, on a technical level, NGSI-LD could support resource identification via IRIs, they decided to allow only URIs (URI \(\subset\) IRI) for the sake of being compliant to the Linked Data principles [47]. Because of the focus on Semantic Web technologies and Linked Data principles, NGSI-LD provides good support for semantic annotations. Serialization happens in JSON-LD, which since version 1.1 is compatible to basic JSON as well as RDF.  
Figure 4: Class diagram depicting the metamodel of the digital twin definition language.  
Resource discovery is realized by a component named 'Context Registry'. NGSI-LD supports different types of architectures: centralized, distributed, and federated. In the centralized architecture, only one context registry exists whereas in the distributed and federated there can be multiple (hierarchically organized) registries. Any registry supports resource discovery via HTTP and custom query languages enabling geo-spatial, temporal and historical queries. Although there are already well-established query languages for RDF such as SPARQL or GeoSPARQL, NGSI-LD decided to define custom query languages from scratch. The reason for this is that NGSI-LD does not use the RDF data format where data is represented as triples in the form of \(<\)subject, predicate, object\(>\) but rather uses the concept of property graphs [48] where predicates of such triples can contain further key-value data.  
Resource access in NGSI-LD is fundamentally different from the other standards as there is no direct communication between producer and consumer. Instead, the producer provides their information to a broker and consumers can then access these data or subscribe to be notified upon changes. These interactions are defined in a communication protocol-agnostic manner but currently only a binding to HTTP is provided.