NGSI-LD

NGSI-LD (Next Generation Service Interface-Linked Data) ist ein Informationsmodell^[1] und eine Programmierschnittstelle^[2], um Kontextinformationen bereitzustellen, abzufragen oder zu abonnieren. Es soll den offenen Austausch von strukturierten Informationen zwischen verschiedenen Interessensgruppen erleichtern und wird in Anwendungsdomänen wie Smart Cities^[3][4][5], Industrie 4.0, Smart Farming^[6][7] sowie allgemeiner für das Internet der Dinge^[8], cyber-physische Systeme, Systems of systems^[9] und digitale Zwillinge^[10] verwendet.

NGSI-LD wurde vom Europäischen Institut für Telekommunikationsnormen (ETSI) durch die Context Information Management Industry Specification Group (ETSI ISG CIM)^[11] auf Vorschlag der Europäischen Kommission standardisiert. Der Einsatz und die Weiterentwicklung von NGSI-LD sind im Rolling Plan für ICT-Standardisierung der EU^[12] ausgeführt. NGSI-LD baut auf einem jahrzehntealten Forschungskorpus im Bereich Kontextmanagement und Kontextmodellierung^[13] auf. Das Akronym NGSI steht für Next Generation Service Interfaces, eine Reihe von Spezifikationen für Programmierschnittstellen, die ursprünglich von der OMA herausgegeben worden waren und unter anderem Programmierschnittstellen für Kontextinformationen^[14] enthielten. Letztere wurden von der Future Internet Public Private Partnership (FI-PPP)^[15] übernommen und als NGSIv2^[16] weiterentwickelt. Aus der FI-PPP ging dann die FIWARE Open Source Community hervor, für die zunächst NGSIv2 und heute NGSI-LD die zentrale Programmierschnittstelle darstellt.

Das NGSI-LD-Informationsmodell repräsentiert Kontextinformationen als Entitäten, die Eigenschaften und Beziehungen zu anderen Entitäten haben. Es ist von Property Graphs^[17] abgeleitet, wobei die Semantik auf der Grundlage von RDF und dem Semantic Web formal definiert ist. NGSI-LD wird als JSON-LD serialisiert. Jede Entität erhält eine eindeutige IRI-Referenz als Kennung, sodass die entsprechenden Daten als Linked-Data-Datensätze exportiert werden können. Das Suffix LD in NGSI-LD kennzeichnet die Zugehörigkeit zum Linked-Data-Universum der verknüpften Daten.

Das NGSI-LD-Informationsmodell^[1] kann als erste formale Spezifikation des Property-Graph-Modells angesehen werden, das von einer de jure Standardorganisation standardisiert wurde. Das Property-Graph-Modell hat sich seit Anfang der 2000er Jahre in informeller Weise als gemeinsamer Nenner für Graphdatenbanken entwickelt.

Die Kernkonzepte sind:

• Ein Property Graph ist ein gerichteter Multigraph, der aus Knoten besteht, die durch gerichtete Kanten miteinander verbunden sind, wobei sowohl Knoten als auch Kanten mehrere optionale Eigenschaften (Attribute) haben können.
• Eigenschaften (ähnlich wie Attribute in Objektmodellen) haben die Form beliebiger Schlüssel-Wert-Paare. Schlüssel sind Zeichenketten und Werte sind beliebige Datentypen. Im Gegensatz zu RDF-Diagrammen sind Eigenschaften keine Kanten des Diagramms.
• Beziehungen sind gerichtete Kanten des Graphen, die immer eine Kennung, einen Startknoten und einen Endknoten haben.

Das NGSI-LD-Metamodell^[1] definiert diese grundlegenden Konzepte (Entitäten, Beziehungen, Eigenschaften) formal auf der Grundlage von RDF/RDFS /OWL und teilweise auf der Grundlage von JSON-LD.

• Eine NGSI-LD-Entity (Entität) ist der informationale Repräsentant von einem Referenten, der in der realen Welt außerhalb des NGSI-LD-basierten Systems existieren soll. Dieser Referent muss weder rein physisch (es kann sich um eine rechtliche oder administrative Einheit handeln) noch eigenständig sein (es kann sich um ein Konstrukt auf verteilter Systemebene handeln). Jede Instanz einer solchen Entität soll durch eine IRI eindeutig identifiziert und durch Bezugnahme auf einen oder mehrere NGSI-LD-Entitätstypen gekennzeichnet werden. In Bezug auf den Property Graph stellt eine NGSI-LD Entity einen Knoten dar.
• Eine NGSI-LD-Property (Eigenschaft) ist eine Instanz, die ein Merkmal (repräsentiert als NGSI-LD-Value) entweder einer NGSI-LD-Entity, einer NGSI-LD-Relationship oder einer anderen NGSI-LD-Property zuordnet. NGSI-LD Properties-of-Properties (Eigenschaften von Eigenschaften) sind ausdrücklich erlaubt und werden z. B. verwendet, um die Genauigkeit eines bestimmten Messwertes auszudrücken.
• Eine NGSI-LD-Relationship (Beziehung) ist eine gerichtete Verbindung zwischen einem Subjekt (Ausgangspunkt), das eine NGSI-LD-Entity, eine NGSI-LD-Property oder eine andere NGSI-LD-Relationship sein kann, und einem Objekt (Endpunkt), das immer eine NGSI-LD-Entity ist. Eine NGSI-LD-Relationship von einer NGSI-LD-Property zu einer NGSI-LD-Entity kann beispielsweise verwendet werden, um auszudrücken, dass die NGSI-LD Property von dieser NGSI-LD Entity gemessen wurde (Provenienz der Messung).
• Ein NGSI-LD-Value ist ein JSON-Wert (d. h. eine Zeichenfolge, eine Zahl, true oder false, ein Objekt, ein Array) oder ein JSON-LD-Wert (d. h. eine Zeichenfolge als lexikalische Form des Werts zusammen mit einem Typ, der durch einen XSD-Basistyp oder allgemeiner durch einen IRI definiert ist, oder ein strukturierter Wert, d. h. eine Menge, eine Liste oder eine Zeichenfolge mit Sprachkennzeichnung).
• Ein NGSI-LD-Type ist eine OWL-Klasse, die eine Unterklasse einer der Klassen NGSI-LD-Entity, NGSI-LD-Relationship, NGSI-LD-Property oder NGSI-LD-Value ist, die im NGSI-LD-Metamodell definiert sind. NGSI-LD definiert eine kleine Anzahl von Typen vor, ist aber ansonsten für alle von Benutzern definierten Typen offen.

Ergänzend zu diesem Metamodell bietet die NGSI-LD-Informationsmodellspezifikation auch eine domänenübergreifende Ontologie^[1], die Schlüsselkonstrukte definiert, die sich auf räumliche, zeitliche oder Systemzusammensetzungseigenschaften von Entitäten beziehen.

Die NGSI-LD-Spezifikation besteht aus einem Informationsmodell und einer Programmierschnittstelle. Die Programmierschnittstelle bietet Funktionen zur Unterstützung der im Folgenden beschriebenen Architekturrollen.

• Context Consumer: Ein Context Consumer konsumiert NGSI-LD-Entities von einem Context Broker (oder möglicherweise direkt von einer Context Source) unter Verwendung der Context Information Consumption-Funktionen der NGSI-LD-Programmierschnittstelle. Er kann eine bestimmte NGSI-LD-Entity abrufen oder relevante NGSI-LD-Entities mithilfe synchroner Anforderungen abfragen. Er kann auch relevante NGSI-LD-Entities abonnieren und asynchrone Benachrichtigungen erhalten, wenn Änderungen an den angeforderten NGSI-LD-Entities vorgenommen werden.
• Context Producer: Ein Context Producer erstellt, aktualisiert und löscht NGSI-LD-Entities, NGSI-LD-Properties und NGSI-LD-Relationships im Context Broker mithilfe der Context Information Provision-Funktionen der NGSI-LD-Programmierschnittstelle.
• Context Source: Eine Context Source stellt NGSI-LD-Entities über die Context Information Consumption-Funktionen der NGSI-LD-Programmierschnittstelle zur Verfügung. Um die Informationen für einen Context Broker verfügbar zu machen, registriert sie die Art der Kontextinformationen, die sie bereitstellen kann, mit einem Registry Server, unter Verwendung der Context-Source-Registrierungs-Funktionen der NGSI-LD-Programmierschnittstelle.
• Context Broker: Ein Context Broker fungiert als primärer Zugriffspunkt auf Kontextinformationen für Context Consumers. Informationen zu NGSI-LD-Entities können vom Context Broker selbst gespeichert werden, wenn sie von einem Context Producer mithilfe der Context Information Provision-Funktionen der NGSI-LD-Programmierschnittstelle bereitgestellt wurden, oder der Context Broker kann mithilfe der Context Consumption Informationen Funktionen der NGSI-LD Programmierschnittstelle Informationen von Context Sources abrufen. Der Context Broker aggregiert alle Informationen zu NGSI-LD-Entities, die auf eine Anforderung passen, und gibt das aggregierte Ergebnis an den Context Consumer zurück. Im Falle eines Abonnements werden Benachrichtigungen gesendet, wenn relevante Änderungen vorliegen, möglicherweise aufgrund des Empfangs von Benachrichtigungen von Context Sources. Um Context Sources zu finden, deren NGSI-LD-Entities möglicherweise für eine Context Consumer-Anforderung relevant sind, verwendet der Context Broker die Context Source Discovery-Funktionalität der vom Registry Server implementierten NGSI-LD-Programmierschnittstelle.
• Registry Server: Ein Registry Server speichert Context-Source-Registrierungen, die von Context Sources unter Verwendung der Context-Source-Registrierungs-Funktionen der NGSI-LD-Programmierschnittstelle bereitgestellt werden. Context-Source-Registrierungen enthalten Informationen darüber, welche Art von Kontextinformationen eine Context Source bereitstellen kann, jedoch keine tatsächlichen Werte. Die Art der Kontextinformationen kann auf verschiedenen Granularitätsstufen bereitgestellt werden. Dies reicht von sehr detaillierten Informationen, z. B. dass bestimmte Properties oder Relationships einer bestimmten NGSI-LD-Entity zur Verfügung gestellt werden, bis zu Informationen einer bestimmten NGSI-LD-Entity (ohne Informationen zu Properties oder Relationships) oder zu der Ebene, auf der NGSI-LD-Entities mit einem bestimmten NGSI-LD-Entity-Type bereitgestellt werden können, möglicherweise für ein bestimmtes geografisches Gebiet. Die Context Source Discovery-Funktionalität der NGSI-LD-Programmierschnittstelle ermöglicht es dem Context Broker (oder möglicherweise einem Context Consumer), Context Sources zu finden, die möglicherweise Informationen zu relevanten NGSI-LD-Entities zur Verfügung stellen.

Die Architekturrollen ermöglichen die Implementierung verschiedener Deploymentarchitekturen. In einer zentralisierten Architektur gibt es einen zentralen Context Broker, der die von Context Producers bereitgestellten Kontextinformationen speichert. In einer verteilten Umgebung können alle Kontextinformationen von Context Sources gespeichert werden. In einer Verbundarchitektur können Context Sources wiederum selbst Context Broker sein, die aggregierte Informationen aus einer niedrigeren Hierarchieebene verfügbar machen. Diese Architekturen schließen sich nicht gegenseitig aus, d. h. ein tatsächliches Deployment kann sie auf unterschiedliche Weise kombinieren.

Die NGSI-LD-Programmierschnittstelle für die Kontextinformationsverwaltung^[2] ermöglicht es Benutzern, Kontextinformationen in mehreren Szenarien und unter Einbeziehung mehrerer Stakeholder bereitzustellen, zu konsumieren und zu abonnieren. Dies ermöglicht den Zugriff auf Kontextinformationen nahezu in Echtzeit aus vielen verschiedenen Quellen (nicht nur IoT-Datenquellen), die als Context Sources bezeichnet werden, sowie die Bereitstellung dieser Informationen über interoperable Datenveröffentlichungsplattformen.

Die NGSI-LD Programmierschnittstelle bietet erweiterte geo-temporale Abfragen und Abonnementmechanismen, um es Kontextkonsumenten (Context Consumers) zu ermöglichen, informiert zu werden, sobald Kontextinformationen verfügbar werden oder sich ändern, die vorgegebenen Filterkriterien entsprechen.

Die NGSI-LD Programmierschnittstelle ist so konzipiert, dass sie unabhängig von der Deployment-Architektur ist (zentral, verteilt, als Verbund oder Kombinationen davon), sodass Anwendungen, die Kontextinformationen zur Verfügung stellen oder konsumieren, nicht auf die Besonderheiten des Systems zugeschnitten werden müssen, das Kontextinformationen für sie verteilt/vermittelt.

API-Operationen umfassen:

• Kontextinformations-Operationen, die sich mit den folgenden Aspekten befassen:
  • Context Information Provision (Erstellen und Löschen von NGSI-LD-Entities und Aktualisieren ihrer Properties und Relationships)
  • Context Information Consumption (Abfragen von NGSI-LD-Entities) und
  • Context Information Subscription (Abonnieren bestimmter Informationen unter bestimmten Bedingungen, um benachrichtigt zu werden, wenn NGSI-LD-Entities mit den benötigten Informationen verfügbar werden)

• Context Source-Operationen, die sich mit den folgenden Aspekten befassen:
  • Context Source Registration (Bereitstellung einer neuen Context Source im verteilten System durch Registrierung) und
  • Context Source Discovery (Abfrage des Systems darüber, welche Context Sources registriert wurden, die bestimmte Kontextinformationen anbieten)

NGSI-LD wurde von Partnern des FIWARE-Programms initiiert und wird aktuell insbesondere von der FIWARE Open Source Community verwendet.

• Die Connecting Europe Facility (CEF) empfiehlt die Verwendung des FIWARE Context Brokers^[18] mit NGSI-LD.^[19]
• Das Open and Agile Smart Cities Netzwerk^[20] verweist auf die NGSI-LD-Spezifikation als ersten ihrer Minimal Interoperability Mechanisms.^[21]
• Das Projekt Living-in.eu^[22] empfiehlt die Verwendung von NGSI-LD in ihrer gemeinsamen Erklärung und ihren technischen Verpflichtungen. Die Erklärung wurde von 86 Städten und öffentlichen Verwaltungen^[23] aus der EU gebilligt und unterzeichnet und wird von vielen weiteren Unternehmen und Organisationen unterstützt.
• Die GSMA IoT Big Data Framework Architecture^[24] basiert auf NGSI-LD.
• Das Fed4IoT EU-Projekt^[25] verwendet NGSI-LD als neutrales Datenformat zum Übersetzen zwischen verschiedenen IoT-Datenrepräsentationen.^[26]
• Die graphbasierte Digitale Zwillings-Plattform Thing'in^[27] von Orange verwendet NGSI-LD als Kerninformationsmodell.^[28]
• Die City Data Hub Plattform^[3] wurde als Teil des Smart City Data Hub Projektes entwickelt und dient jetzt als Basis für Smart Cities in Südkorea^[29].
• India Urban Data Exchange (IUDX)^[30] nutzt NGSI-LD als Teil ihres Resource Access Service Interfaces. Das Bureau of Indian Standards referenziert NGSI-LD in seinem 'Standard Unified Data Exchange IS 18003(Part2):2021'^[31]

• Orion-LD von der FIWARE Foundation^[32]
• Scorpio von NEC^[33]
• Stellio von EGM^[34][35]
• Cassiopeia von GeoNet.MRN e.V.^[36][37] und der Metropolregion Rhein-Neckar GmbH
• City Data Hub von KETI^[38]

NGSI-LD ist das Ergebnis einer Weiterentwicklung der Kontextschnittstellen, die im Rahmen der 2012 von der Open Mobile Alliance (OMA) veröffentlichten Suite Next Generation Service Interfaces (NGSI)^[39] begann. Dies ist auch der Ursprung des Akronyms NGSI. Die NGSI-Suite enthielt NGSI-9 als Context Entity Discovery Interface und NGSI-10 als Context Information Interface.^[14] Der NGSI-Standard der OMA und seine initialen Weiterentwicklungen stützten sich auf ein klassisches Entity-Attribut-Wert-Modell und eine XML-basierte Darstellung. Die NGSI-Kontextschnittstellen wurden vom FI-WARE-Projekt überarbeitet, das die Plattform für das European Future Internet Public-Private-Partnership (FI-PPP) entwickelte. Im Zuge dessen haben die OMA NGSI Context Interfaces ein HTTP-Binding mit einer JSON-Repräsentanten erhalten, was als NGSIv1 bezeichnet wurde und sowohl NGSI-9 als auch NGSI-10 umfasste. Im Verlauf des FI-PPP wurden die Schnittstellen zu NGSIv2 weiterentwickelt, das zur Schlüsselschnittstelle der FIWARE-Plattform wurde. Nach dem Ende des FI-PPP im Jahr 2016 wurde die FIWARE-Plattform zum Kern der FIWARE Open Source Community, die von der FIWARE Foundation verwaltet wird. Im Jahr 2017 wurde die ETSI Industry Specification Group for cross-cutting Context Information Management (ETSI ISG CIM)^[11] gegründet, um die NGSI Kontextschnittstelle als Standard weiterzuentwickeln, was zur Schaffung von NGSI-LD führte. Um die Einschränkungen des ursprünglichen Informationsmodells zu überwinden, wurde ein umfassenderes Modell spezifiziert, das sich aus dem Property-Graph-Modell ableitet und explizite Relationships zwischen Entitäten enthält. ETSI ISG CIM entwickelt das NGSI-LD Information Model und die NGSI-LD API kontinuierlich weiter. ETSI veröffentlicht ein- oder zweimal im Jahr neue Versionen der Spezifikationen.

• ETSI CIM group home page
• NGSI-LD Primer (oriented towards the use of the API)
• NGSI-LD modelling guidelines White Paper

1. ↑ ^{a b c d} NGSI-LD Information Model Specification
2. ↑ ^{a b} NGSI-LD API Specification
3. ↑ ^{a b} Seungmyeong Jeong, Seongyun Kim, Jaeho Kim: City Data Hub: Implementation of Standard-Based Smart City Data Platform for Interoperability. In: MDPI sensors. 20. Jahrgang, Nr. 23, 7. Dezember 2020, doi:10.3390/s20237000 (englisch, mdpi.com [abgerufen am 7. Februar 2024]). 
4. ↑ João Almeida, Jorge Silva, Thais Silva, Everton Cavalcante: A Linked Data-based Service for Integrating Heterogeneous Data Sources in Smart Cities. 22nd International Conference on Enterprise Information Systems. In: Proceedings of the 22nd International Conference on Enterprise Information Systems (ICEIS). Band 1. SciTePress, 2020, ISBN 978-989-758-423-7, S. 205–212, doi:10.5220/0009422802050212 (englisch, scitepress.org [PDF; abgerufen am 7. Februar 2024]). 
5. ↑ NGSI-LD Resources. In: oascities.org. Open Agile Smart Cities, 11. Dezember 2019, abgerufen am 7. Februar 2024 (englisch). 
6. ↑ Juan Antonio López-Morales, Juan Antonio Martinez, Antonio F. Skarmeta: Digital Transformation of Agriculture through the Use of an Interoperable Platform. In: MDPI sensors. 20. Jahrgang, Nr. 4, 24. Januar 2020, doi:10.3390/s20041153 (englisch, mdpi.com [abgerufen am 7. Februar 2024]). 
7. ↑ Fabio Viola, Francesco Antoniazzi, Cristiano Antoniazzi, Carlos Kamienski, Luca Roffia: Mapping the NGSI-LD Context Model on Top of a SPARQL Event Processing Architecture: Implementation Guidelines. 24th Conference of Open Innovations Association (FRUCT). IEEE, Moscow, Russia April 2019, doi:10.23919/FRUCT.2019.8711888 (englisch, ieee.org [abgerufen am 7. Februar 2024]). 
8. ↑ Flavio Cirillo, Gürkan Solmaz, Everton Luís Berz, Martin Bauer, Bin Cheng, Ernö Kovacs: A Standard-Based Open Source IoT Platform: FIWARE. In: IEEE IoT Magazine. 2. Jahrgang, Nr. 3, September 2019, doi:10.1109/IOTM.0001.1800022 (englisch, ieee.org [abgerufen am 7. Februar 2024]). 
9. ↑ Ulrich Ahle, Ernö Kovacs, Andreas Linneweber, Wolfgang Möller, Bernd Simon.: SMART CITY ÖKOSYSTEM: Fundament legen - Entscheidungshoheit nutzen. FIWARE und SAP, Oktober 2020, abgerufen am 7. Februar 2024: „S.6, In heutigen Smart Cities werden derartige “System-of-Systems” auf der Basis der ETSI Norm “Context Information Management (ETSI ISG CIM)” mit dem Namen NGSI-LD realisiert.“ 
10. ↑ Olivier Bloch, Miriam Berhane Russon, Gert de Tant: Smart Cities Ontology for Digital Twins. In: Internet of Things Show. MSDN Channel 9, 26. Februar 2021, abgerufen am 7. Februar 2024 (englisch). 
11. ↑ ^{a b} Industry Specification Group (ISG) Cross Cutting Context Information Management (CIM). ETSI, abgerufen am 7. Februar 2024 (englisch). 
12. ↑ Rolling Plan 2022. In: Rolling plan for ICT standardisation. European Comission, abgerufen am 7. Februar 2024 (englisch). 
13. ↑ A survey of context modelling and reasoning techniques
14. ↑ ^{a b} Martin Bauer, Ernö Kovacs, Anett Kovacs, Naoko Ito, Carmen Criminisi, Laurent-Walter Goix, Massimo Vallo: The Context API in the OMA Next Generation Service Interface. 14th International Conference on Intelligence in Next Generation Networks. In: Proceedings of the 14th International Conference on Intelligence in Next Generation Networks (ICIN). IEEE, Berlin, Germany 2010, doi:10.1109/ICIN.2010.5640931 (englisch, ieee.org [abgerufen am 7. Februar 2024]). 
15. ↑ Future Internet Public Private Partnership. European Comission, archiviert vom Original am 1. April 2017; abgerufen am 27. April 2022 (englisch).  Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis.@1@2Vorlage:Webachiv/IABot/ec.europa.eu 
16. ↑ José Manuel Cantera Fonseca, Fermín Galán Márquez, Tobias Jacobs: FIWARE-NGSI v2 Specification. FIWARE, abgerufen am 7. Februar 2024 (englisch). 
17. ↑ "The Property Graph Database Model"
18. ↑ CEF Context Broker
19. ↑ CEF Context Broker Standards
20. ↑ We bring together smart cities & communities worldwide to shape the global market for digital services. Abgerufen am 7. Februar 2024 (englisch). 
21. ↑ Minimal Interoperability Mechanisms (MIM1). Abgerufen am 7. Februar 2024 (englisch). 
22. ↑ Join us in building the European way of Digital Transformation for 300 million Europeans. Abgerufen am 7. Februar 2024 (englisch). 
23. ↑ Living-eu Declaration Signers
24. ↑ GSMA IoT Big Data Framework Architecture
25. ↑ A cloud of things. Fed4IoT, abgerufen am 7. Februar 2024 (englisch). 
26. ↑ Andrea Detti, Giuseppe Tropea, Giulio Rossi, Juan A. Martinez, Antonio F. Skarmeta, Hidenori Nakazato: Virtual IoT Systems: Boosting IoT Innovation by Decoupling Things Providers and Applications Developers. In: 2019 Global IoT Summit (GIoTS). IEEE, Aarhus, Dänemark 2019, S. 1–6, doi:10.1109/GIOTS.2019.8766422 (englisch, ieee.org). 
27. ↑ Thing in the future is a multi-sided open digital twin platform to fuel innovations and develop new services ! orange, abgerufen am 7. Februar 2024 (englisch). 
28. ↑ Thing'in Information Model. orange, abgerufen am 7. Februar 2024 (englisch). 
29. ↑ Validation of NGSI-LD test Platform and Examples of uses
30. ↑ India Urban Data Exchange. IUDX, abgerufen am 7. Februar 2024 (englisch). 
31. ↑ BIS Adopts IUDX Architecture and API Specifications as Standard for Data Exchange. Buereau of Indian Standards, 2022, abgerufen am 7. Februar 2024 (englisch). 
32. ↑ Context Broker and CEF building block for context data management which supports both the NGSI-LD and the NGSI-v2 APIs. FIWARE, abgerufen am 7. Februar 2024 (englisch). 
33. ↑ NEC Scorpio NGSI-LD Context Broker promoted to full Generic Enabler of FIWARE for context management. NEC Laboratories Europe, 18. Dezember 2020, abgerufen am 7. Februar 2024 (englisch). 
34. ↑ Stellio is an NGSI-LD compatible context broker. Abgerufen am 7. Februar 2024 (englisch). 
35. ↑ Who are we? EGM, abgerufen am 7. Februar 2024 (englisch). 
36. ↑ An ongoing project to implement a light-weight and fast NGSI-LD broker in TypeScript, running on Node.js and using PostgreSQL + PostGIS as storage back-end. geonet-mrn, abgerufen am 7. Februar 2024 (englisch). 
37. ↑ Willkommen bei GeoNet.MRN. Abgerufen am 7. Februar 2024. 
38. ↑ City Data Hub Data Core Module. Abgerufen am 7. Februar 2024 (englisch). 
39. ↑ OMA Next Generation Service Interfaces Architecture