NGSI-LD
| Abbreviation | NGSI-LD |
|---|---|
| Status | ETSI Group Specification |
| Year started | 2017 |
| Organization | ETSI |
| Authors | ISG CIM (Industry Specification Group) of ETSI |
| Base standards | RDF, RDFS, OWL, JSON, JSON-LD,HTTP, URI |
| Domain | Information_model,Linked Data, Semantic Web, |
| Website | CIM group page @ETSI |
NGSI-LD is an information model and API for publishing, querying and subscribing to Context Information. It is meant to facilitate the open exchange and sharing of structured information between different stakeholders, across application domains such as Smart Cities, Smart Industry, Smart Agriculture, and more generally for the Internet of Things, Cyber-Physical Systems, Systems of systems and Digital Twins.
NGSI-LD is being standardized by ETSI through the Context Information Management Industry Specification Group and represents the latest step in the decades-old evolution of context management interfaces and frameworks. The acronym NGSI stands for "Next Generation Service Interfaces", a suite of specifications originally issued by the OMA which included Context Interfaces. These were taken up and evolved as NGSIv2 by the European Future Internet Public-Private-Partnership (PPP), which spawned the FIWARE open source community.
The NGSI-LD information model represents Context Information as entities that have properties and relationships to other entities. It is derived from property graphs[1], but with semantics formally defined on the basis of RDF and the semantic web framework. It can be serialized using JSON-LD. Every entity and relationship must be given a unique IRI reference as identifier, making the corresponding data exportable as Linked data datasets. The -LD suffix denotes this affiliation to the Linked Data universe.
Design
Information Model
The NGSI-LD information model 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 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 formally defines these foundational concepts (Entities, Relationships, Properties) on the basis of RDF/RDFS/OWL, and partially on the basis of JSON-LD.
- An NGSI-LD 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.
- An NGSI-LD 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.
- An NGSI-LD 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).
- An NGSI-LD 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).
- An NGSI-LD 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[2] provides a cross-domain ontology that defines key constructs related to spatial, temporal or system-composition characteristics of entities.
Architecture
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 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.
API
The NGSI-LD Context Information Management API[3] 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).
Uses
NGSI-LD was initiated by partners of the FIWARE programme, and is primarily used by the FIWARE open source community.[4], supported by the FIWARE Foundation[5]
- 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 mentions the NGSI-LD specification in their technical commitments
- The GSMA "IoT Big Data Framework Architecture"
- The Thing'in graph-based digital twin platform from Orange
Implementations in Open source software projects
History
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. 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, 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 Inustry 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.