Wikipedia

NGSI-LD

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[1][2][3], Industria 4.0, Agricoltura di precisione[4][5] e più in generale per l'Internet delle cose[6], i Sistemi ciberfisici, i "sistemi di sistemi" (Systems of systems)[7] e i gemelli digitali[8].

NGSI-LD ISG CIM - Context Information Management
TipoISG - Industry Specification Group
Affiliazione internazionaleETSI
Fondazione2017
Sito web

NGSI-LD è standardizzato da ETSI (European Telecommunications Standardization Institute), attraverso il Context Information Management Industry Specification Group, a seguito di una richiesta[9] della Commissione europea. La sua diffusione, e il suo ulteriore sviluppo, sono descritti nel "Rolling plan for ICT standardization" dell'UE[10]. 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[11]. L'acronimo NGSI sta per "Next Generation Service Interfaces", che è una suite di specifiche, originariamente emessa dall'OMA, che includeva Context Interfaces[12] . Queste specifiche sono poi state riprese, e si sono evolute in NGSIv2[13] , 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à[14], 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 modifica

Modello di informazioni modifica

Il modello di informazioni di NGSI-LD[15] 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[15] 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[15] (cioè adatta a più domini applicativi diversi) che definisce i costrutti chiave relativi alle caratteristiche spaziali, temporali o di composizione delle Entità.

Architettura modifica

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 modifica

L'API per il Context Information Management di NGSI-LD[16] 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 modifica

NGSI-LD è stato avviato dai partner del programma FIWARE ed è utilizzato principalmente dalla comunità open source FIWARE[17], supportata dalla FIWARE Foundation[18] , così come da una vasta gamma di altri progetti, dei quali alcuni sono elencati qui nel seguito:

Implementazioni in progetti software Open source modifica

Storia modifica

NGSI-LD è il risultato di un'evoluzione iniziata come parte della suite "Next Generation Service Interfaces" (NGSI) pubblicata da Open Mobile Alliance (OMA) nel 2012, che è anche la fonte della sigla NGSI. La suite NGSI includeva NGSI-9 come Context Entity Discovery Interface e NGSI-10 come Context Information Interface[12]. Lo standard NGSI di OMA e le sue evoluzioni intermedie si basavano su un classico modello Entità-Attributo-Valore e una rappresentazione basata su XML. Le Context Interfaces NGSI sono poi state adattate dal progetto FI-WARE, che ha sviluppato la piattaforma per il partenariato pubblico-privato (PPP) della Future Internet Europea. Le interfacce NGSI OMA avevano una implementazione via HTTP con una rappresentazione JSON, denominata NGSIv1, che include sia NGSI-9 che NGSI-10. Nel corso di FI-PPP le interfacce sono state ulteriormente evolute in NGSIv2,[13] che è diventata l'interfaccia chiave della piattaforma FIWARE. Dopo la fine del FI-PPP nel 2016, la piattaforma FIWARE è diventata il cuore della FIWARE Open Source Community gestita dalla FIWARE Foundation . Nel 2017, l'ETSI "Industry Specification Group on cross-cutting Context Information Management" (ETSI ISG CIM) è stato creato per evolvere quella Context Information Interface, il che ha portato alla creazione di NGSI-LD. I limiti del modello di informazioni originale hanno portato alla specificazione di un modello più ampio, che deriva dai grafi di proprietà, e che include esplicitamente le relazioni tra entità, trattandole alla pari delle entità stesse.

Note modifica

  1. ^ a b Seungmyeong Jeong, Seongyun Kim e Jaeho Kim, City Data Hub: Implementation of Standard-Based Smart City Data Platform for Interoperability, in MDPI sensors, vol. 20, n. 23, 7 dicembre 2020, DOI:10.3390/s20237000. URL consultato il 24 marzo 2021.
  2. ^ vol. 1, 2020, DOI:10.5220/0009422802050212, ISBN 978-989-758-423-7, https://www.scitepress.org/Papers/2020/94228/94228.pdf.
  3. ^ oascities.org, https://oascities.org/tag/ngsi-ld/. URL consultato il 24 marzo 2021.
  4. ^ Juan Antonio López-Morales, Juan Antonio Martinez e Antonio F. Skarmeta, Digital Transformation of Agriculture through the Use of an Interoperable Platform, in MDPI sensors, vol. 20, n. 4, 24 gennaio 2020, DOI:10.3390/s20041153. URL consultato il 24 marzo 2021.
  5. ^ DOI:10.23919/FRUCT.2019.8711888, https://ieeexplore.ieee.org/abstract/document/8711888.
  6. ^ Flavio Cirillo, Gürkan Solmaz e Everton Luís Berz, A Standard-Based Open Source IoT Platform: FIWARE, in IEEE IoT Magazine, vol. 2, n. 3, settembre 2019, DOI:10.1109/IOTM.0001.1800022, arXiv:2005.02788. URL consultato il 24 marzo 2021.
  7. ^ fiware.org, https://www.fiware.org/wp-content/uploads/Whitepaper-FIWARE-SAP_English.pdf. URL consultato il 24 marzo 2021.
    «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. ^ https://channel9.msdn.com/Shows/Internet-of-Things-Show/Smart-Cities-Ontology-for-Digital-Twins.
  9. ^ (EN) Anonymous, The 2016 Rolling Plan for ICT Standardisation is released, su Internal Market, Industry, Entrepreneurship and SMEs - European Commission, 25 febbraio 2016. URL consultato il 29 aprile 2021.
  10. ^ (EN) Rolling Plan 2021 | Joinup, su joinup.ec.europa.eu. URL consultato il 29 aprile 2021.
  11. ^ (EN) Claudio Bettini, Oliver Brdiczka e Karen Henricksen, A survey of context modelling and reasoning techniques, in Pervasive and Mobile Computing, vol. 6, n. 2, 1º aprile 2010, pp. 161–180, DOI:10.1016/j.pmcj.2009.06.002. URL consultato l'8 marzo 2023.
  12. ^ a b (EN) Martin Bauer, Ernö Kovacs e Anett Schülke, The Context API in the OMA Next Generation Service Interface, in 2010 14th International Conference on Intelligence in Next Generation Networks, 2010-10, pp. 1–5, DOI:10.1109/ICIN.2010.5640931. URL consultato l'8 marzo 2023.
  13. ^ a b José Manuel Cantera Fonseca, Fermín Galán Márquez, Tobias Jacobs, fiware.github.io, https://fiware.github.io/specifications/ngsiv2/stable/. URL consultato il 27 marzo 2021.
  14. ^ "The Property Graph Database Model"
  15. ^ a b c NGSI-LD information model specification
  16. ^ NGSI-LD API specification
  17. ^ https://github.com/Fiware
  18. ^ a b https://www.fiware.org
  19. ^ Living-eu technical commitments
  20. ^ https://www.living-in.eu/declaration/we-signed
  21. ^ https://www.living-in.eu/supporters
  22. ^ Andrea Detti, Giuseppe Tropea e Giulio Rossi, Virtual IoT Systems: Boosting IoT Innovation by Decoupling Things Providers and Applications Developers, in 2019 Global IoT Summit (GIoTS), IEEE, 2019, pp. 1–6, DOI:10.1109/GIOTS.2019.8766422, ISBN 978-1-7281-2171-0.
  23. ^ Information Model, su thinginthefuture.com, 2019.
  24. ^ Validation of NGSI-LD test Platform and Examples of uses
  25. ^ India Urban Data Exchange, su iudx.org.in.
  26. ^ BIS Adopts IUDX Architecture and API Specifications as Standard for Data Exchange, su iudx.org.in, 2022.
  27. ^ NEC Scorpio NGSI-LD Context Broker promoted to full Generic Enabler of FIWARE for context management, su neclab.eu, NEC Laboratories Europe, 18 dicembre 2020.

Voci correlate modifica

Collegamenti esterni modifica

Estratto da "https://it.wikipedia.org/w/index.php?title=NGSI-LD&oldid=138560816"