NGSI-LD

Le modèle d'information NGSI-LD^[3] peut être considéré comme la première spécification formelle par un organisme de normalisation de jure du modèle des graphes attribués, qui a émergé depuis le début des années 2000 comme un modèle informel, dénominateur commun pour les bases de données orientées graphes. Les concepts de base sont:

• Un graphe attribué est un multigraphe orienté, composé de nœuds (sommets) reliés par des liens orientés, où les nœuds et les liens peuvent tous deux avoir plusieurs attributs/propriétés attachés.
• Les propriétés (similaires aux attributs des modèles objet) ont la forme de paires clé-valeur arbitraires. Les clés sont des chaînes et les valeurs sont des types de données arbitraires. Contrairement aux graphes RDF, les propriétés ne sont pas des arcs du graphe.
• Les relations sont des arcs (arêtes orientées ) du graphe, qui ont toujours un identifiant, un nœud de départ et un nœud de fin

Le métamodèle NGSI-LD définit formellement ces concepts fondamentaux (Entités, Relations, Propriétés) sur la base de RDF / RDFS / OWL, et partiellement sur la base de JSON-LD.

• Une Entité NGSI-LD est le représentant informationnel de quelque chose (un référent) qui est supposé exister dans le monde réel, en dehors de la plate-forme informatique utilisant NGSI-LD. Ce référent peut être un objet physique, un être vivant, un système physiquement réparti, voire une entité légale ou administrative. Toute instance d'une telle entité est supposée être identifiée de manière unique par un IRI, et caractérisée par référence à un ou plusieurs types d'entités NGSI-LD. Dans le langage des graphes attribués, c'est un nœud.
• Une Propriété NGSI-LD est une instance qui associe une caractéristique, une valeur NGSI-LD, à une entité NGSI-LD, à une relation NGSI-LD ou à une autre propriété NGSI-LD. Les propriétés des propriétés sont explicitement autorisées et sont encouragées, par exemple pour qualifier la précision d'une valeur mesurée particulière.
• Une Relation 'NGSI-LD est un lien orienté entre un sujet (point de départ), qui peut être une entité NGSI-LD, une propriété NGSI-LD ou une autre relation NGSI-LD, et un objet (point final), qui est une autre entité NGSI-LD. Une relation NGSI-LD d'une propriété à une entité peut par exemple être utilisée pour exprimer que la propriété a été mesurée par cette entité (provenance de la mesure).
• Une Valeur NGSI-LD est une valeur JSON (c'est-à-dire une chaîne, un nombre, vrai ou faux, un objet, un tableau), ou une valeur typée JSON-LD (c'est-à-dire une chaîne comme forme lexicale de la valeur avec un type, défini par un type de base XSD ou plus généralement un IRI), ou une valeur structurée JSON-LD (c'est-à-dire un ensemble, une liste ou une chaîne marquée par une langue).
• Un Type NGSI-LD est une classe OWL qui est une sous-classe des classes entité, relation, propriété ou valeur telles que définies dans le méta-modèle NGSI-LD. NGSI-LD prédéfinit un petit nombre de types, mais est par ailleurs ouvert à tous les types définis par les utilisateurs.

En complément de ce métamodèle, la spécification du modèle d'information NGSI-LD fournit une ontologie inter-domaines qui définit les catégories clés liées aux caractéristiques spatiales, temporelles ou de composition de système .

La spécification NGSI-LD se compose d'un modèle d'information et d'une API. L'API fournit des fonctionnalités pour prendre en charge les rôles architecturaux décrits ci-dessous.

• Consommateur de contexte : Un consommateur de contexte consomme des entités NGSI-LD d'un courtier de contexte (ou éventuellement directement d'une source de contexte) en utilisant les fonctionnalités de consommation d'informations de contexte de l'API NGSI-LD.Il peut récupérer un NGSI spécifique -LD Entité ou interroger les entités NGSI-LD pertinentes à l'aide de requêtes synchrones. Il peut également s'abonner aux entités NGSI-LD pertinentes et recevoir des notifications asynchrones chaque fois qu'il y a des changements dans les entités NGSI-LD demandées.
• Producteur de contexte : Un producteur de contexte crée, met à jour et supprime les entités NGSI-LD, les propriétés NGSI-LD et les relations NGSI-LD dans le courtier de contexte à l'aide des fonctionnalités de fourniture d'informations de contexte de l'API NGSI-LD.
• Source de contexte : Une source de contexte rend les entités NGSI-LD disponibles via les fonctionnalités de consommation d'informations de contexte de l'API NGSI-LD. Pour rendre les informations détectables pour un courtier de contexte, il enregistre le type d'informations de contexte qu'il peut fournir avec un serveur de registre à l'aide de la fonctionnalité d'enregistrement de source de contexte de l'API NGSI-LD.
• Context Broker : Un context broker ("courtier" de contexte) agit comme le principal point d'accès aux informations contextuelles pour les Consommateurs de Contexte. Les informations d'entités NGSI-LD peuvent être stockées par le courtier de contexte lui-même, si elles ont été fournies par un producteur de contexte à l'aide des fonctionnalités de fourniture d'informations de contexte de l'API NGSI-LD, ou le courtier peut demander à partir de sources de contexte en utilisant la consommation d'informations de contexte fonctionnalités de l'API NGSI-LD. Le courtier de contexte regroupe toutes les informations d'entité NGSI-LD liées à une demande et renvoie le résultat agrégé au courtier de contexte. Dans le cas d'un abonnement, il envoie des notifications chaque fois qu'il y a des changements pertinents, potentiellement à la suite de la réception de notifications de sources de contexte. Pour trouver des sources de contexte qui peuvent avoir des entités NGSI-LD pertinentes pour une demande de consommateur de contexte, le courtier de contexte utilise la fonctionnalité de découverte de source de contexte de l'API NGSI-LD implémentée par le serveur de registre.
• Registry Server : Le serveur de registre stocke les enregistrements de source de contexte fournis par les sources de contexte à l'aide des fonctionnalités d'enregistrement de source de contexte de l'API NGSI-LD. Les enregistrements de sources de contexte contiennent des informations sur le «type» d'informations de contexte qu'une source de contexte peut fournir, mais pas sur les valeurs réelles. Le type d'informations contextuelles peut être fourni à différents niveaux de granularité allant des informations très détaillées, par ex. certaines propriétés ou relations d'une entité NGSI-LD spécifique, à toute information d'une entité NGSI-LD spécifique, ou au niveau qu'elle peut fournir des entités NGSI-LD qui ont un certain type d'entité, éventuellement pour une zone géographique donnée. La fonctionnalité de découverte de source de contexte de l'API NGSI-LD permet au courtier de contexte (ou éventuellement à un consommateur de contexte) de trouver des sources de contexte qui peuvent avoir des entités NGSI-LD pertinentes.

Les rôles architecturaux permettent la mise en œuvre de différentes architectures de déploiement. Dans une architecture centralisée, il existe un courtier de contexte central qui stocke les informations de contexte fournies par les producteurs de contexte. Dans un environnement distribué, toutes les informations de contexte peuvent être stockées par des sources de contexte. Dans une architecture fédérée, les sources de contexte peuvent à nouveau être des courtiers de contexte qui mettent à disposition des informations agrégées d'un niveau hiérarchique inférieur. Ces architectures ne sont pas mutuellement exclusives, c'est-à-dire qu'un déploiement réel peut les combiner de différentes manières.

L'API de gestion des informations de contexte NGSI-LD ^[4] permet aux utilisateurs de fournir, de consommer et de s'abonner à des informations contextuelles dans plusieurs scénarios et impliquant plusieurs parties prenantes. Il permet un accès quasiment en temps réel à des informations provenant de nombreuses sources différentes (pas seulement des sources de données IoT), nommées "sources de contexte" , ainsi que la publication de ces informations via des plates-formes de publication de données interopérables.

Elle fournit des requêtes géo-temporelles avancées et inclut des mécanismes d'abonnement, afin que les consommateurs de contenu soient avertis lorsqu'un contenu correspondant à certaines contraintes devient disponible.

L'API est conçue pour être indépendante de l'architecture (centrale, distribuée, fédérée ou des combinaisons de celles-ci), de sorte que les applications qui produisent et consomment des informations n'ont pas à être adaptées aux spécificités du système qui distribue / courtage les informations de contexte pour elles.

Les opérations de l'API comprennent:

• Opérations 'Informations contextuelles' , concernant 'Provision' (création d'entités NGSI-LD et mise à jour de leurs attributs), 'Consommation' (interrogation d'entités NGSI-LD) et 'Abonnement' (souscription à des informations spécifiques, sous des contraintes spécifiées, afin d'être notifié lorsque des entités correspondantes apparaissent, portant les informations spécifiées).

• Opérations 'Sources de contexte' , concernées par 'Enregistrement' (rendre une nouvelle source d'informations de contexte disponible dans le système distribué global, en l'enregistrant) et 'Découverte' (interroger le système sur les sources de contexte enregistrées, qui offrent des informations d'un type spécifié).

Alors que les premières définitions du contexte dans les TIC avaient tendance à être centrées sur les utilisateurs, ou les appareils interfacés directement avec les utilisateurs, la définition souvent citée de Dey^[5] (" toute information pouvant être utilisée pour caractériser la situation d'un entité ") peut être comprise sans cette restriction. Le contexte centré sur l'utilisateur, tel qu'il est utilisé dans la conception d' interfaces humaines, peut également impliquer une séparation trop simple et partiellement arbitraire entre le "contenu" (tout ce qui est explicitement entré par les utilisateurs, ou lu/vu par eux), et le contexte, qui est implicite , et utilisé à des fins d'adaptation. Une vision plus dynamique et décentrée, mise en avant par un article célèbre de Paul Dourish ("De quoi parle-t-on quand on parle de contexte?")^[6] considère le contexte comme essentiellement «relationnel». Cela correspondait à l'origine au passage de l'informatique personnelle à l'informatique ubiquitaire, mais provient aussi d'une compréhension plus large de l'intelligence ambiante où les distinctions entre contexte et contenu deviennent relatives et dynamiques^[7]. Dans cette vue, les sources d'informations (telles que les capteurs de l'Internet des objets) qui peuvent être du contexte pour certaines applications, peuvent également être des sources de contenu primaire pour d'autres, et vice versa. Ce qui compte, c'est l'ensemble des relations qui les lient, ensemble et avec leur environnement. Alors que les premières descriptions du contexte centré sur un utilisateur unique pouvaient être adaptées aux modèles de données classiques associant à des entités un ensemble d'attributs, des modèles d'information plus polyvalents, basés sur des graphes , comme proposé avec NGSI-LD, sont mieux adaptés pour saisir la vision plus relationnelle du contexte qui est pertinente pour l'Internet des objets, les systèmes cyber-physiques et les jumeaux numériques. Dans cette acception plus large, le contexte n'est pas seulement vu comme un ensemble d'attributs attachés à une entité, il est d'abord représenté par un graphe qui capture les relations de cette entité avec d'autres. La connaissance du contexte est la capacité de prendre en compte ces informations transverses provenant de sources multiples.

NGSI-LD est le résultat d'une évolution des interfaces de contexte qui a débuté dans le cadre de la suite «Next Generation Service Interfaces» (NGSI) publiée par l' Open Mobile Alliance (OMA) en 2012, qui est également la source de l'acronyme NGSI. La suite NGSI comprenait NGSI-9 comme interface de découverte d'entité de contexte et NGSI-10 comme interface d'informations de contexte. La norme NGSI de l'OMA et ses évolutions intermédiaires reposaient sur un modèle classique Entité – attribut – valeur et une représentation basée sur XML. Les interfaces contextuelles NGSI ont été adaptées par le projet FI-WARE, qui a développé la plate-forme pour le futur partenariat public-privé(PPP) européen "Internet du Futur" . Les interfaces de contexte OMA NGSI ont obtenu une liaison HTTP avec une représentation JSON, appelée NGSIv1, qui comprenait à la fois NGSI-9 et NGSI-10. Au cours de FI-PPP, les interfaces ont évolué vers NGSIv2, qui est devenue l'interface clé de la plate-forme FIWARE. Après la fin du FI-PPP en 2016, la plate-forme FIWARE est devenue le noyau de la communauté Open Source FIWARE gérée par la FIWARE Foundation. En 2017, le groupe "ISG (industry Specification Group) de l'ETSI sur la gestion transversale des informations contextuelles (ETSI ISG CIM) a été créé pour faire évoluer l'interface d'informations contextuelles, ce qui a abouti à la création de NGSI-LD. Les limites du modèle d'information original ont conduit à la spécification d'un modèle plus large qui dérive des graphes attribués, incluant explicitement les relations entre les entités, au même titre que les entités elles-mêmes.

NGSI-LD a été lancé par des partenaires du programme FIWARE, et est principalement utilisé par la communauté open source FIWARE, supportée par la Fondation FIWARE

• Le programme Connecting Europe Facilities (CEF) recommande l'utilisation du context broker FIWARE [1] avec NGSI-LD
• La Open and Agile Smart Cities Organization fait référence à la spécification NGSI-LD comme la première de ses Minimal Interoperability Mechanisms
• Le projet Living-in.eu mentionne la spécification NGSI-LD dans ses technical engagements
• Le Framework "IoT Big Data" spécifié par la GSMA
• La plate-forme de jumeaux numériques basée-graphes Thing'in d'Orange
• La plateforme India Urban Data Exchanges [IUDX]^[8] utilise l'API NGSI-LD dans le cadre de son interface de service d'accès aux ressources. Il est référencé dans la norme Unified Data Exchange IS 18003(Part2):2021 standard^[9].

• Orion-LD
• Scorpio de NEC
• Stellio

• Web des données
• JSON-LD
• Base de données orientée graphe
• Graphes attribués

• (en) ETSI CIM group home page
• (en) NGSI-LD Primer (orienté vers l'utilisation de l'API)
• (en) NGSI-LD modelling guidelines White Paper

•   Portail de l’informatique
•   Portail des données