Information model edit

The NGSI-LD information model^[15] can be considered as the first formal specification by a de jure standards organization of the property graph model, which has emerged since the early 2000s as an informal common denominator model for graph databases.

The core concepts are:

• A property graph is a directed multigraph, made up of nodes (vertices) connected by directed links, where nodes and arcs both may have multiple optional attached properties (i.e. attributes)
• Properties (similar to attributes in object models) have the form of arbitrary key-value pairs. Keys are character strings and values are arbitrary data types. By contrast to RDF graphs, properties are not arcs of the graph.
• Relationships are arcs (directed edges) of the graph, which always have an identifier, a start node and an end node

The NGSI-LD meta-model^[15] formally defines these foundational concepts (Entities, Relationships, Properties) on the basis of RDF/RDFS/OWL, and partially on the basis of JSON-LD.

• An entity is the informational representative of something (a referent) that is supposed to exist in the real world, outside of the computational platform using NGSI-LD. This referent need not be something strictly physical (it could be a legal or administrative entity), nor self-contained (it may be a distributed system-level construct). Any instance of such an entity is supposed to be uniquely identified by an IRI, and characterized by reference to one or more NGSI-LD Entity Type(s). In property-graph language, it is a node.
• A property is an instance that associates a characteristic, an NGSI-LD Value, to either an NGSI-LD Entity, an NGSI-LD Relationship or another NGSI-LD Property. Properties of properties are explicitly allowed and are encouraged e.g. to express the accuracy of a particular measured value.
• A relationship is a directed link between a subject (starting point), that may be an NGSI-LD Entity, an NGSI-LD Property, or another NGSI-LD Relationship, and an object (end-point), that is an NGSI-LD Entity. A NGSI-LD Relationship from a Property to an Entity can for example be used to express that the Property was measured by that Entity (Provenance of the measurement).
• A value is a JSON value (i.e. a string, a number, true or false, an object, an array), or a JSON-LD typed value (i.e. a string as the lexical form of the value together with a type, defined by an XSD base type or more generally an IRI), or a JSON-LD structured value (i.e. a set, a list, or a language-tagged string).
• A type is an OWL class that is a subclass of either the NGSI-LD Entity, NGSI-LD Relationship, NGSI-LD Property or NGSI-LD Value classes defined in the NGSI-LD meta-model. NGSI-LD pre-defines a small number of types, but is otherwise open to any types defined by users.

Complementing this metamodel, the NGSI-LD information model specification also provides a cross-domain ontology^[15] that defines key constructs related to spatial, temporal or system-composition characteristics of entities.

The flexible information model allows the specification of any kind of entity. In order to allow interoperability between NGSI-LD users, standardized entities are collaboratively defined at Smart Data Models Program and made available at its repository with an open-source license.

Architecture edit

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.

• 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 Consumer. 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.

API edit

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] as well as a diverse range of other projects and users such as below:

• The Connecting Europe Facility recommends the use of the FIWARE context broker with NGSI-LD
• The Open & Agile Smart Cities & Communities (OASC) organisation references the NGSI-LD specification as the first of their Minimal Interoperability Mechanisms (MIM1).^[19]
• The Living-in.eu project recommends the use of NGSI-LD in their joint declaration and their technical commitments.^[20] The declaration has been endorsed and signed by 86 cities and public administrations^[21] from the EU, and is supported by many more companies and organizations.^[22]
• The GSMA "IoT Big Data Framework Architecture" is based on NGSI-LD.^[23]
• The Fed4IoT EU project, where it is used as a neutral data format^[24] 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.^[25]
• The City Data Hub platform ^[1] has been developed as part of the Smart City Data Hub project and is now used as a basis for smart cities in Korea.^[26]
• The India Urban Data Exchange (IUDX)^[27] uses the NGSI-LD API as part of their Resource Access Service Interface. It is referenced in the Bureau of Indian Standards' Unified Data Exchange IS 18003(Part2):2021 standard.^[28]

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. ETSI ISG CIM continues to evolve the NGSI-LD Information Model and API. It publishes new versions of the specification once or twice a year.

• Context awareness
• Graph Query Language

• ETSI CIM group home page

Implementations in open-source software projects

• Orion-LD from the FIWARE Foundation
• Scorpio from NEC
• Stellio from EGM
• Cassiopeia from Geonet
• City Data Hub Data Core Module from KETI