NGSI-LD (Next Generation Service Interface-Linked Data) ist ein InformationsmodellNGSI-LD Information Model Specification und eine ProgrammierschnittstelleNGSI-LD API Specification, 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 KontextmodellierungA survey of context modelling and reasoning techniques 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"The Property Graph Database Model" 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.
600px|NGSI-LD-Architektur-Interaktionen
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