NGSI-LD - A graph-based context information model and API
AbbreviationNGSI-LD
StatusETSI Group Specification
Year started2017
OrganizationETSI
AuthorsISG CIM (Industry Specification Group) of ETSI
Base standardsRDF, RDFS, OWL, JSON, JSON-LD, HTTP, URI
DomainInformation model, linked data, semantic web
WebsiteCIM 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. It is used across application domains such as smart cities,[1][2][3] smart industry, smart agriculture,[4][5] and more generally for the Internet of things,[6] cyber-physical systems, systems of systems[7] and digital twins.[8]

NGSI-LD has been standardized by ETSI (European Telecommunications Standardization Institute) through the Context Information Management Industry Specification Group, following a request[9] from the European Commission. Its takeup and further development are spelled out in the EU's "Rolling plan for ICT standardization".[10] NGSI-LD builds upon a decades-old corpus of research in context management frameworks and context modelling.[11] The acronym NGSI stands for "Next Generation Service Interfaces", a suite of specifications originally issued by the OMA which included Context Interfaces.[12] These were taken up and evolved as NGSIv2[13] 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,[14] 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 is 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[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

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

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

Uses

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 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.[22]
  • The Fed4IoT EU project, where it is used as a neutral data format[23] 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.

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

See also

References

  1. ↑ Jeong, Seungmyeong; Kim, Seongyun; Kim, Jaeho (2020-12-07). "City Data Hub: Implementation of Standard-Based Smart City Data Platform for Interoperability". Sensors. 20 (23): 7000. Bibcode:2020Senso..20.7000J. doi:10.3390/s20237000. PMC 7731156. PMID 33297506.
  2. ↑ Almeida, João; Silva, Jorge; Batista, Thais; Cavalcante, Everton (2020). "Proceedings of the 22nd International Conference on Enterprise Information Systems". Proceedings of the 22nd International Conference on Enterprise Information Systems (ICEIS). Vol. 1. SciTePress. pp. 205–212. doi:10.5220/0009422802050212. ISBN 978-989-758-423-7.
  3. ↑ "NGSI-LD Resources". oascities.org. Open Agile Smart Cities. 2019-12-11. Retrieved 2021-03-24.
  4. ↑ López-Morales, Juan Antonio; Martinez, Juan Antonio; Skarmeta, Antonio F. (2020-01-24). "Digital Transformation of Agriculture through the Use of an Interoperable Platform". Sensors. 20 (4): 1153. Bibcode:2020Senso..20.1153L. doi:10.3390/s20041153. PMC 7070948. PMID 32093147.
  5. ↑ Viola, Fabio; Antoniazzi, Francesco; Aguzzi, Cristiano; Kamienski, Carlos; Roffia, Luca (April 2019). "Mapping the NGSI-LD Context Model on Top of a SPARQL Event Processing Architecture: Implementation Guidelines". 2019 24th Conference of Open Innovations Association (FRUCT). 24th Conference of Open Innovations Association (FRUCT). Moscow, Russia: IEEE. pp. 493–501. doi:10.23919/FRUCT.2019.8711888. hdl:11585/698548. ISBN 978-952-68653-8-6.
  6. ↑ Cirillo, Flavio; Solmaz, Gürkan; Berz, Everton Luís; Bauer, Martin; Cheng, Bin; Kovacs, Ernö (September 2019). "A Standard-Based Open Source IoT Platform: FIWARE". IEEE IoT Magazine. 2 (3): 12–18. arXiv:2005.02788. doi:10.1109/IOTM.0001.1800022. S2CID 210693632. Retrieved 2021-03-24.
  7. ↑ Ulrich Ahle; Ernö Kovacs; Andreas Linneweber; Wolfgang Möller; Bernd Simon. (October 2020). "SMART CITY ECOSYSTEM: Laying the foundations - using decision-making sovereignty" (PDF). FIWARE and SAP. Retrieved 2021-03-24. p.6, In today's Smart Cities "System-of-Systems" architectures are created on the basis of the ETSI standard "Context Information Management (ETSI ISG CIM)" also known as NGSI-LD.
  8. ↑ Olivier Bloch, Miriam Berhane Russon, Gert de Tant (February 26, 2021). "Smart Cities Ontology for Digital Twins". Internet of Things Show. MSDN Channel 9. Retrieved 2021-03-24.
  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. 1 2 Bauer, Martin; Kovacs, Ernö; Schülke, Anett; Ito, Naoko; Criminisi, Carmen; Goix, Laurent-Walter; Valla, Massimo (2010). "2010 14th International Conference on Intelligence in Next Generation Networks". Proceedings of the 14th International Conference on Intelligence in Next Generation Networks (ICIN). Berlin, Germany: IEEE. pp. 1–5. doi:10.1109/ICIN.2010.5640931. ISBN 978-1-4244-7443-1.
  13. 1 2 José Manuel Cantera Fonseca, Fermín Galán Márquez, Tobias Jacobs. "FIWARE-NGSI v2 Specification". FIWARE. Retrieved 2021-03-27.{{cite web}}: CS1 maint: multiple names: authors list (link)
  14. ↑ "The Property Graph Database Model"
  15. 1 2 3 NGSI-LD information model specification
  16. ↑ NGSI-LD API specification
  17. ↑ "FIWARE". GitHub.
  18. ↑ "Home". fiware.org.
  19. ↑ Living-eu technical commitments
  20. ↑ "We signed". 6 December 2019.
  21. ↑ "Supporting the declaration". June 2023.
  22. ↑ "IoT Big Data Framework Architecture"
  23. ↑ Detti, Andrea; Tropea, Giuseppe; Rossi, Giulio; Martinez, Juan A.; Skarmeta, Antonio F.; Nakazato, Hidenori (2019). "Virtual IoT Systems: Boosting IoT Innovation by Decoupling Things Providers and Applications Developers". 2019 Global IoT Summit (GIoTS). Aarhus, Denmark: IEEE. pp. 1–6. doi:10.1109/GIOTS.2019.8766422. ISBN 978-1-7281-2171-0. S2CID 198145674.
Implementations in open-source software projects
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.