# NGSI-LD

NGSI-LD (Next Generation Service Interface-Linked Data) ist ein Informationsmodell und eine Programmierschnittstelle, 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, Industrie 4.0, Smart Farming sowie allgemeiner für das Internet der Dinge, cyber-physische Systeme, Systems of systems und digitale Zwillinge verwendet.
NGSI-LD wurde vom Europäischen Institut für Telekommunikationsnormen (ETSI) durch die Context Information Management Industry Specification Group (ETSI ISG CIM) 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 ausgeführt. NGSI-LD baut auf einem jahrzehntealten Forschungskorpus im Bereich Kontextmanagement und Kontextmodellierung 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 enthielten. Letztere wurden von der Future Internet Public Private Partnership (FI-PPP) übernommen und als NGSIv2 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 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.

## Design
### Informationsmodell

Das NGSI-LD-Informationsmodell 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 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, die Schlüsselkonstrukte definiert, die sich auf räumliche, zeitliche oder Systemzusammensetzungseigenschaften von Entitäten beziehen.

### Architektur

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.

### Programmierschnittstelle

Die NGSI-LD-Programmierschnittstelle für die Kontextinformationsverwaltung 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)

## Nutzung

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 mit NGSI-LD.
* Das Open and Agile Smart Cities Netzwerk verweist auf die NGSI-LD-Spezifikation als ersten ihrer Minimal Interoperability Mechanisms.
* Das Projekt Living-in.eu 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 aus der EU gebilligt und unterzeichnet und wird von vielen weiteren Unternehmen und Organisationen unterstützt.
* Die GSMA IoT Big Data Framework Architecture basiert auf NGSI-LD.
* Das Fed4IoT EU-Projekt verwendet NGSI-LD als neutrales Datenformat zum Übersetzen zwischen verschiedenen IoT-Datenrepräsentationen.
* Die graphbasierte Digitale Zwillings-Plattform Thing'in von Orange verwendet NGSI-LD als Kerninformationsmodell.
* Die City Data Hub Plattform wurde als Teil des Smart City Data Hub Projektes entwickelt und dient jetzt als Basis für Smart Cities in Südkorea.
* India Urban Data Exchange (IUDX) 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'

## Implementierungen in Open-Source-Software-Projekten

* Orion-LD von der FIWARE Foundation
* Scorpio von NEC
* Stellio von EGM

## Geschichte

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) 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. 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) 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.