NGSI-LD

NGSI-LD ist ein Informationsmodell und eine Programmierschnittstelle, um Kontextinformationen zu veröffentlichen, abzufragen oder zu abonnieren. Es soll den offenen Austausch von strukturierten Informationen zwischen verschiedenen Interessensgruppen erleichtern. Es wird in Anwendungsdomänen wie Smart Cities ^{[1] [2] [3]} , Industrie 4.0, Smart Farming ^{[4] [5]} , und allgemeiner für das Internet der Dinge ^[6] , cyber-physische Systeme, Systems of systems^[7] und digitale Zwillinge ^[8] 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^[9] standardisiert. Der Einsatz und die Weiterentwicklung von NGSI-LD sind im "Rolling Plan für IKT-Standardisierung" der EU ^[10] ausgeführt. NGSI-LD baut auf einem jahrzehntealten Forschungskorpus im Bereich Kontextmanagement und Kontextmodellierung ^[11] 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 wurden und, unter anderem, Programmierschnittstellen für Kontextinformationen^[12] enthielten. Letztere wurden vom "Future Internet - Public-Private Partnership"(FI-PPP) übernommen und als NGSIv2^[13] weiterentwickelt. Aus dem 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 ^[14] 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, so dass 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^[15] 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 Graphkdatenbanken 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 ^[15] 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 Represäntant von etwas (einem Referenten), das 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-Entity-Types (Entitätstyp) 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 ^[15] , die Schlüsselkonstrukte definiert, die sich auf räumliche, zeitliche oder Systemzusammensetzungseigenschaften von Entitäten beziehen.

The NGSI-LD specification consists of an information model and an API. The API provides functionalities to support the architectural roles described in the following.

NGSI-LD Architecture Interactions

• Context Consumer: A Context Consumer consumes NGSI-LD Entities from a Context Broker (or possibly directly from a Context Source) using the Context Information Consumption functionalities of the NGSI-LD API.It can retrieve a specific NGSI-LD Entity or query relevant NGSI-LD Entities using synchronous requests. It can also subscribe for relevant NGSI-LD Entities and receive asynchronous notifications whenever there are changes in the requested NGSI-LD Entities.
• Context Producer: A Context Producer creates, updates and deletes NGSI-LD Entities, NGSI-LD Properties and NGSI-LD Relationships in the Context Broker using the Context Information Provision functionalities of the NGSI-LD API.
• Context Source: A Context Source makes NGSI-LD Entities available through the Context Information Consumption functionalities of the NGSI-LD API. To make the information discoverable for a Context Broker, it registers the kind of context information it can provide with a Registry Server using the Context Source Registration functionality of the NGSI-LD API.
• Context Broker: A Context Broker acts as the primary access points to context information for Context Consumers. NGSI-LD Entity information can be stored by the Context Broker itself, if it has been provided by a Context Producer using the Context Information Provision functionalities of the NGSI-LD API, or the Broker can request is from Context Sources using the Context Information Consumption functionalities of the NGSI-LD API. The Context Broker aggregates all NGSI-LD Entity information related to a request and returns the aggregated result to the Context Broker. In the case of a subscription, it sends notifications whenever there are relevant changes, potentially as a result of receiving notifications from Context Sources. To find Context Sources that may have NGSI-LD Entities relevant to a Context Consumer request, the Context Broker uses the Context Source Discovery functionality of the NGSI-LD API implemented by the Registry Server.
• Registry Server: The Registry Server stores Context Source Registrations provided by Context Sources using the Context Source Registration functionalities of the NGSI-LD API. Context Source Registrations contain information about what kind of Context Information a Context Source can provide, but not actual values. The kind of context information can be provided on different granularity levels ranging from very detailed information, e.g. certain properties or relationships of a specific NGSI-LD Entity, to any information of a specific NGSI-LD Entity, or to the level that it can provide NGSI-LD Entities that have a certain Entity Type, possibly for a given geographic area. The Context Source Discovery functionality of the NGSI-LD API allows the Context Broker (or possibly a Context Consumer) to find Context Sources that may have relevant NGSI-LD Entities.

The architectural roles allow the implementation of different deployment architectures. In a centralized architectures, there is a central Context Broker that stores the context information provided by Context Producers. In a distributed setting, all context information can be stored by Context Sources. In a federated architecture, Context Sources can again be Context Brokers that make aggregated information from a lower hierarchy level available. These architectures are not mutually exclusive, i.e. an actual deployment may combine them in different ways.

The NGSI-LD Context Information Management API^[16] allows users to provide, consume and subscribe to context information in multiple scenarios and involving multiple stakeholders. It enables close to real-time access to information coming from many different sources (not only IoT data sources), named Context Sources, as well as publishing that information through interoperable data publication platforms.

It provides advanced geo-temporal queries, and it includes subscription mechanisms, in order for content consumers to be notified when content matching some constraints becomes available.

The API is designed to be agnostic to the architecture (central, distributed, federated or combinations thereof), so that applications which produce and consume information do not have to be tailored to the specifics of the system that distributes/brokers context information for them.

API operations comprise:

• Context Information operations, concerned with Provision (creating NGSI-LD Entities, and updating their Attributes), Consumption (querying NGSI-LD Entities) and Subscription (subscribing to specific information, under specified constraints, in order to be notified when matching Entities appear, carrying the specified information).

• Context Sources operations, concerned with Registration (make a new source of context information available in the overall distributed system, by registering it) and Discovery (querying the system about what context sources have registered, which offer information of a specified type).

NGSI-LD was initiated by partners of the FIWARE programme, and is primarily used by the FIWARE open source community^[17] , supported by the FIWARE Foundation^[18]

• The Connecting Europe Facility recommends the use of the FIWARE context broker with NGSI-LD
• The Open and Agile Smart Cities Organisation references the NGSI-LD specification as the first of their Minimal Interoperability Mechanisms
• The Living-in.eu project recommends the use of NGSI-LD in their joint declaration and their technical commitments ^[19] . The declaration has been endorsed and signed by 86 cities and public administrations ^[20] from the EU, and is supported by many more companies and organizations^[21]
• The GSMA "IoT Big Data Framework Architecture" is based on NGSI-LD
• The Fed4IoT EU project, where it is used as a neutral data format^[22] for translating between various IoT data representations
• The Thing'in graph-based digital twin platform from Orange uses NGSI-LD as its core information model

• Orion-LD from the FIWARE Foundation ^[18]
• Scorpio from NEC ^[23]
• Stelliofrom EGM
• Cassiopeia from Geonet

NGSI-LD is the result of an evolution of Context Interfaces that started as part of the "Next Generation Service Interfaces" (NGSI) suite published by the Open Mobile Alliance (OMA) in 2012, which is also the source of the acronym NGSI. The NGSI suite included NGSI-9 as the Context Entity Discovery Interface and NGSI-10 as the Context Information Interface^[12] . The NGSI standard from OMA and its intermediary evolutions relied on a classical Entity–attribute–value model and an XML-based representation. The NGSI Context Interfaces were adapted by the FI-WARE project, which developed the platform for the European Future Internet Public-Private-Partnership (PPP). The OMA NGSI Context Interfaces got an HTTP binding with a JSON representation, referred to as NGSIv1, which included both NGSI-9 and NGSI-10. In the course of FI-PPP the interfaces further evolved into NGSIv2^[13] , which became the key interface of the FIWARE platform. After the end of the FI-PPP in 2016, the FIWARE platform became the core of the FIWARE Open Source Community managed by the FIWARE Foundation. In 2017, the ETSI Industry Specification Group on cross-cutting Context Information Management (ETSI ISG CIM) was created to evolve the Context Information Interface, which resulted in the creation of NGSI-LD. The limitations of the original information model led to the specification of a broader model which derives from property graphs, explicitly including relationships between entities, on a par with entities themselves.

• Linked data
• Context management
• Context awareness
• Graph database
• Graph Query Language

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

1. ↑ 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 (mdpi.com). 
2. ↑ João Almeida, Jorge Silva, Thais Silva, Everton Cavalcante: A Linked Data-based Service for Integrating Heterogeneous Data Sources in Smart Cities. 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 (scitepress.org [PDF]). Fehler bei Vorlage * Pflichtparameter fehlt (Vorlage:Cite conference): conference; language
3. ↑ NGSI-LD Resources. In: oascities.org. Open Agile Smart Cities, 11. Dezember 2019; abgerufen im 1. Januar 1. 
4. ↑ 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 (mdpi.com). 
5. ↑ 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 (ieee.org). Fehler bei Vorlage * Pflichtparameter fehlt (Vorlage:Cite conference): language
6. ↑ 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 (ieee.org). 
7. ↑ 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 2. April 2021: „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." 
8. ↑ 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 2. April 2021 (englisch). 
9. ↑ | "EU 2016 rolling plan for ICT Standardisation"
10. ↑ | "EU 2021 rolling plan for ICT Standardisation"
11. ↑ | "A survey of context modelling and reasoning techniques"
12. ↑ ^{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. In: Proceedings of the 14th International Conference on Intelligence in Next Generation Networks (ICIN). IEEE, Berlin, Germany 2010, doi:10.1109/ICIN.2010.5640931 (ieee.org). Fehler bei Vorlage * Pflichtparameter fehlt (Vorlage:Cite conference): conference; language
13. ↑ ^{a b} José Manuel Cantera Fonseca, Fermín Galán Márquez, Tobias Jacobs: FIWARE-NGSI v2 Specification. FIWARE, abgerufen am 3. April 2021. 
14. ↑ "The Property Graph Database Model"
15. ↑ ^{a b c} NGSI-LD Information Model Specification
16. ↑ NGSI-LD API specification
17. ↑ https://github.com/Fiware
18. ↑ ^{a b} https://www.fiware.org
19. ↑ Living-eu technical commitments
20. ↑ https://www.living-in.eu/declaration/we-signed
21. ↑ https://www.living-in.eu/supporters
22. ↑ 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, Denmark 2019, S. 1–6, doi:10.1109/GIOTS.2019.8766422 (ieee.org). Fehler bei Vorlage * Parametername unbekannt (Vorlage:Cite journal): "isbn" Fehler beim Aufruf der Vorlage:Cite journal: Evtl. falsche Vorlage mit Parameter 'isbn' eingebunden, evtl. ändern auf Cite book.
23. ↑ Vorlage:Cite press release

Vorlage:Data exchange [[Category:Information science]] [[Category:Knowledge representation]] [[Category:Modeling languages]] [[Category:Computer standards]] [[Category:Telecommunications standards]]

• Wikipedia:Vorlagenfehler/Vorlage:Cite journal/temporär
• Wikipedia:Vorlagenfehler/Vorlage:Cite conference
• Wikipedia:Vorlagenfehler/Vorlage:Cite web/temporär
• Wikipedia:Vorlagenfehler/Vorlage:Cite journal
• Benutzer:Importartikel
• Benutzer:Importartikel 04 - 2021