NGSI-LD è un modello di informazioni e una API per l'interrogazione, la pubblicazione di, e la sottoscrizione a informazioni di contesto. Ha lo scopo di facilitare uno scambio aperto e una facile condivisione di informazioni strutturate tra le diverse parti interessate. Viene utilizzato in domini applicativi come Città Intelligenti, Industria 4.0, Agricoltura di precisione e più in generale per l'Internet delle cose, i Sistemi ciberfisici, i "sistemi di sistemi" (Systems of systems) e i gemelli digitali.
NGSI-LD è standardizzato da ETSI (European Telecommunications Standardization Institute), attraverso il Context Information Management Industry Specification Group, a seguito di una richiesta della Commissione europea. La sua diffusione, e il suo ulteriore sviluppo, sono descritti nel "Rolling plan for ICT standardization" dell'UE. NGSI-LD si basa su un corpus di ricerca sui framework e sui modelli per la gestione di informazioni di contesto, consolidatosi in vari anni. L'acronimo NGSI sta per "Next Generation Service Interfaces", che è una suite di specifiche, originariamente emessa dall'OMA, che includeva Context Interfaces . Queste specifiche sono poi state riprese, e si sono evolute in NGSIv2 , dalla European Future Internet Public-Private-Partnership (PPP), che ha generato la comunità open source FIWARE.
NGSI-LD rappresenta le informazioni di contesto come entità che hanno proprietà e relazioni con altre entità. Esso è derivato dai grafi di proprietà, con una semantica formalmente definita sulla base di RDF, e del web semantico. Può essere serializzato utilizzando JSON-LD. A ogni entità e relazione viene assegnato, come identificatore, un riferimento IRI univoco, rendendo i dati corrispondenti esportabili come set di dati collegati. Il suffisso -LD denota infatti questa affiliazione all'universo Linked Data.
Design
Modello di informazioni Il modello di informazioni di NGSI-LD può essere considerato come la prima specifica formale, creata da un organismo di standardizzazione de jure, dei grafi di proprietà, che sono emersi dall'inizio degli anni 2000 come un modello informale che servisse da denominatore comune per le basi di dati a grafo.
I concetti fondamentali sono:
Un grafo di proprietà è un multigrafo diretto, composto da nodi (vertici) collegati da collegamenti diretti, dove i nodi e gli archi possono entrambi avere più proprietà opzionali allegate (cioè attributi) Le proprietà (simili agli attributi nei modelli a oggetti) sono in forma di coppie chiave-valore arbitrarie. Le chiavi sono stringhe di caratteri e i valori sono tipi di dato arbitrari. A differenza dei grafi RDF, le proprietà non sono archi del grafo. Le relazioni sono archi (orientati) del grafo, che hanno sempre un identificatore, un nodo iniziale e un nodo finale.
Il meta-modello NGSI-LD definisce formalmente questi concetti fondamentali (Entità, Relazioni, Proprietà) sulla base di RDF / RDFS / OWL, e parzialmente sulla base di JSON-LD.
Una Entità NGSI-LD rappresenta, a livello di informazione, qualcosa (un referente) che dovrebbe esistere nel mondo reale, al di fuori della piattaforma di calcolo che sta utilizzando NGSI-LD. Questo referente non deve essere qualcosa di strettamente fisico (potrebbe essere un'entità legale o amministrativa), né auto-contenuto (potrebbe essere un costrutto distribuito). Qualsiasi istanza di tale entità dovrebbe essere identificata in modo univoco da un IRI e caratterizzata dal riferimento a uno (o più) Tipi di Entità NGSI-LD. Nel linguaggio tipico dei grafi di proprietà, è un nodo. Una Proprietà NGSI-LD è un'istanza che associa una caratteristica, un Valore NGSI-LD, ad una Entità NGSI-LD, oppure ad una Relazione NGSI-LD, oppure ancora ad un'altra Proprietà NGSI-LD. Proprietà di proprietà sono esplicitamente consentite e sono incoraggiate, ad esempio, per esprimere l'accuratezza di un particolare valore misurato. Una Relazione NGSI-LD è un collegamento diretto tra un soggetto (punto di partenza, che può essere una Entità NGSI-LD, una Proprietà NGSI-LD, o un'altra Relazione NGSI-LD), e un oggetto (end-point), che è sempre una Entità NGSI-LD. Ad esempio, una relazione NGSI-LD da una proprietà a un'entità può essere utilizzata per esprimere che la proprietà è stata misurata da tale entità ("provenienza" della misurazione). Un Valore NGSI-LD è un valore JSON (ovvero una stringa, un numero, vero o falso, un oggetto, un array), o un valore tipizzato JSON-LD (ovvero una stringa che rappresenta in forma lessicale il valore, insieme a un tipo, definito da un tipo di base XSD o più in generale da un IRI), oppure ancora un valore strutturato JSON-LD (cioè un set, una lista oppure una stringa con tag di lingua). Un Tipo NGSI-LD è una classe OWL definita come sottoclasse o della classe Entità NGSI-LD, o della classe Relazione NGSI-LD, o della classe Proprietà NGSI-LD, oppure ancora della classe Valore NGSI-LD definite nel meta-modello NGSI-LD. In NGSI-LD sono stati pre-definiti un piccolo numero di tipi, ma per il resto il sistema è aperto a tutti i possibili tipi definiti dagli utenti.
A complemento di questo meta-modello di base, la specifica relativa al modello di informazioni di NGSI-LD fornisce anche un'ontologia cross-domain (cioè adatta a più domini applicativi diversi) che definisce i costrutti chiave relativi alle caratteristiche spaziali, temporali o di composizione delle Entità.
Architettura NGSI-LD specifica sia un modello di informazioni che un'API. L'API fornisce funzionalità per supportare i ruoli architetturali descritti di seguito.
Context Consumer: un Context Consumer consuma Entità NGSI-LD da un Context Broker (o possibilmente direttamente da una Context Source) utilizzando le funzionalità di Context Information Consumption dell'API NGSI-LD. Può recuperare una specifica Entità NGSI-LD o interrogare Entità NGSI-LD di interesse, utilizzando richieste sincrone. Può anche sottoscriversi ad Entità NGSI-LD di interesse e ricevere notifiche asincrone ogni volta che ci sono modifiche nelle Entità NGSI-LD richieste. Context Producer: un Context Producer crea, aggiorna ed elimina le Entità NGSI-LD, le Proprietà NGSI-LD e le Relazioni NGSI-LD nel Context Broker, utilizzando le funzionalità di Context Information Provision dell'API NGSI-LD. Context Source: una Context Source rende disponibili le Entità NGSI-LD tramite le funzionalità Context Information Consumption dell'API NGSI-LD. Per rendere le informazioni rilevabili da un Context Broker, registra il tipo di informazioni di contesto che essa può fornire, in un Registry Server, utilizzando la funzionalità Context Source Registration dell'API NGSI-LD. Context Broker: un Context Broker funge da punto di accesso principale alle informazioni di contesto per i Context Consumers. Le informazioni sull'Entità NGSI-LD possono essere memorizzate nel Context Broker stesso, se sono state fornite da un Context Producer utilizzando le funzionalità di Context Information Provision dell'API, oppure il Broker può richiederle da Context Sources esterne utilizzando le funzionalità di Context Information Consumption. Il Context Broker aggrega tutte le informazioni relative all'Entità NGSI-LD inerenti ad una richiesta, e restituisce il risultato aggregato al Context Consumer. Nel caso di una sottoscrizione, invia notifiche ogni volta che sono presenti modifiche rilevanti, potenzialmente a seguito della ricezione di notifiche da altre Context Sources. Per trovare Context Sources che possono avere Entità NGSI-LD rilevanti per una richiesta da parte di un Context Consumer, il Broker utilizza la funzionalità di Context Source Discovery dell'API, implementata dal Registry Server. Registry Server: il Registry Server memorizza le Context Source Registrations fornite dalle Context Sources, utilizzando le funzionalità di Context Source Registration dell'API NGSI-LD. Le Context Source Registrations contengono informazioni sulla tipologia di informazioni di contesto che una sorgente può fornire, ma non sui valori effettivi. La descrizione di queste tipologie può essere fornita a diversi livelli di granularità, andando da informazioni molto dettagliate (ad esempio quali proprietà o relazioni di una specifica Entità NGSI-LD), fino a comprendere, ad esempio, tutte le Entità NGSI-LD che hanno un determinato Tipo, magari per una data area geografica. Poi, laifunzionalità di Context Source Discovery dell'API NGSI-LD consente ai Broker (o eventualmente a un Context Consumer) di scoprire quali Context Sources abbiano Entità NGSI-LD di certe tipologie di interesse.
Questi ruoli consentono l'implementazione di diverse architetture di distribuzione. Nel caso centralizzato, è presente un Context Broker centrale che memorizza le informazioni di contesto fornite dai Context Producers. Nel caso distribuito, tutte le informazioni di contesto possono essere memorizzate da Context Sources. Nel caso federato, le Context Sources sono, a loro volta, Context Brokers che rendono disponibili informazioni aggregate provenienti da un livello gerarchico inferiore. Queste architetture non si escludono a vicenda, e una implementazione effettiva può combinarle in modi diversi.
API L'API per il Context Information Management di NGSI-LD consente agli utenti di fornire, utilizzare e sottoscriversi a informazioni di contesto in scenari variegati e coinvolgendo più parti. Consente l'accesso alle informazioni provenienti da molte fonti diverse (non solo fonti di dati IoT), le Context Sources, e permette la loro pubblicazione attraverso piattaforme dati interoperabili, con prestazione vicine al tempo-reale.
Essa fornisce query geo-temporali avanzate e include meccanismi di sottoscrizione, in modo che i consumatori di contenuti vengano avvisati quando il contenuto che soddisfa i vincoli desiderati diventa disponibile.
L'API è progettata per essere agnostica rispetto all'architettura (centrale, distribuita, federata o loro combinazioni), in modo che le applicazioni che producono e consumano informazioni non debbano essere adattate alle specifiche del sistema che distribuisce / gestisce le informazioni di contesto per loro.
L'API comprendono le seguenti operazioni:
Operazioni relative alla fornitura (creazione di entità NGSI-LD e aggiornamento dei loro attributi), consumo (interrogazione di entità NGSI-LD) e sottoscrizione (sottoscrizione di informazioni specifiche, in base a vincoli specificati, al fine di essere avvisati quando entità corrispondenti, che portano le informazioni specificate, diventano disponibili). Operazioni relative alla registrazione (rendere disponibile una nuova fonte di context information nel sistema distribuito globale, registrandola) e Discovery (interrogare il sistema su quali fonti, ovvero Context Sources, sono state registrate, che offrono informazioni di un tipo specificato).
Usi NGSI-LD è stato avviato dai partner del programma FIWARE ed è utilizzato principalmente dalla comunità open source FIWAREhttps://github.com/Fiware, supportata dalla FIWARE Foundation , così come da una vasta gamma di altri progetti, dei quali alcuni sono elencati qui nel seguito:
La Connecting Europe Facility raccomanda l'uso del Context Broker FIWARE con NGSI-LD. L'organizzazione Open and Agile Smart Cities fa riferimento alla specifica NGSI-LD come primo dei loro meccanismi di interoperabilità minima. Il progetto Living-in.eu raccomanda l'uso di NGSI-LD nella loro dichiarazione congiunta e nei loro impegni tecnici. La dichiarazione è stata approvata e firmata da 86 città e amministrazioni pubbliche dell'UE ed è sostenuta da molte altre società e organizzazionihttps://www.living-in.eu/supporters. La GSMA "IoT Big Data Framework Architecture" è basata su NGSI-LD. Il progetto Fed4IoT EU, utilizza NGSI-LD come formato dati "neutro" per la traduzione tra diverse rappresentazioni di dati IoT. La piattaforma basata su grafi Thing'in di Orange, relativa ai gemelli digitali, utilizza NGSI-LD come modello di informazioni fondante.