NGSI-LD

NGSI-LD - En grafbaserad kontextinformationsmodell och API
Förkortning NGSI-LD
Status ETSI Group Specifikation
Året började 2017
Organisation ETSI
Författare ISG CIM (Industry Specification Group) från ETSI
Basstandarder RDF , RDFS , OWL , JSON , JSON-LD , HTTP , URI
Domän Informationsmodell , länkad data , semantisk webb
Hemsida CIM-gruppsida @ETSI

NGSI-LD är en informationsmodell och API för att publicera , fråga och prenumerera kontextinformation . Det är tänkt att underlätta öppet utbyte och delning av strukturerad information mellan olika intressenter. Det används över applikationsdomäner som smarta städer , smart industri , smart jordbruk och mer allmänt för sakernas Internet , cyberfysiska system , systemsystem och digitala tvillingar .

NGSI-LD har standardiserats av ETSI (European Telecommunications Standardization Institute) genom Context Information Management Industry Specification Group, efter en begäran från Europeiska kommissionen . Dess användning och vidareutveckling beskrivs i EU:s "Rullande plan för IKT-standardisering". NGSI-LD bygger på en decennier gammal samling av forskning inom för kontexthantering och kontextmodellering. Akronymen NGSI står för "Next Generation Service Interfaces", en uppsättning specifikationer som ursprungligen utfärdades av OMA och som inkluderade kontextgränssnitt. Dessa togs upp och utvecklades som NGSIv2 av European Future Internet Public-Private-Partnership (PPP), som skapade FIWARE open source-gemenskapen.

NGSI-LD-informationsmodellen representerar kontextinformation som enheter som har egenskaper och relationer till andra enheter. Den härrör från egenskapsgrafer, med semantik formellt definierad på basis av RDF och det semantiska webbramverket . Det kan serialiseras med JSON-LD . Varje enhet och relation ges en unik IRI -referens som identifierare, vilket gör att motsvarande data kan exporteras som [länkade data]] datamängder. Suffixet -LD anger denna koppling till det länkade datauniversumet.

Design

Informationsmodell

NGSI-LD-informationsmodellen kan betraktas som den första formella specifikationen av en de jure standardorganisation av egenskapsgrafmodellen, som har dykt upp sedan början av 2000-talet som en informell gemensam nämnarmodell för grafdatabaser .

Kärnkoncepten är:

  • En egenskapsgraf är en riktad multigraf , som består av noder (vertices) sammankopplade med riktade länkar, där noder och bågar båda kan ha flera valfria bifogade egenskaper (dvs. attribut)
  • Egenskaper (liknande attribut i objektmodeller) har formen av godtyckliga nyckel-värdepar. Nycklar är teckensträngar och värden är godtyckliga datatyper. Till skillnad från RDF-grafer är egenskaper inte bågar av grafen.
  • Relationer är bågar (riktade kanter ) av grafen, som alltid har en identifierare, en startnod och en slutnod

NGSI-LD -metamodellen definierar formellt dessa grundläggande begrepp (Entiteter, Relationer, Egenskaper) på basis av RDF / RDFS / OWL , och delvis på basis av JSON-LD .

  • En entitet är den informativa representanten för något (en referent ) som antas existera i den verkliga världen, utanför beräkningsplattformen som använder NGSI-LD. Denna referent behöver inte vara något strikt fysiskt (det kan vara en juridisk eller administrativ enhet), och inte heller fristående (det kan vara en distribuerad systemnivåkonstruktion). Varje instans av en sådan entitet antas vara unikt identifierad av en IRI och karakteriserad genom hänvisning till en eller flera NGSI-LD Entity Type(s). I egenskapsgrafspråk är det en nod.
  • En egenskap är en instans som associerar en egenskap, ett NGSI-LD-värde, till antingen en NGSI-LD-enhet, en NGSI-LD-relation eller en annan NGSI-LD-egenskap. Egenskaper hos fastigheter är uttryckligen tillåtna och uppmuntras t.ex. för att uttrycka noggrannheten för ett visst uppmätt värde.
  • En relation är en riktad länk mellan ett ämne (startpunkt), som kan vara en NGSI-LD-enhet, en NGSI-LD-egenskap eller en annan NGSI-LD-relation, och ett objekt (slutpunkt), det vill säga en NGSI- LD Entitet. En NGSI-LD-relation från en fastighet till en enhet kan till exempel användas för att uttrycka att egendomen mättes av den enheten ( mätningens härkomst ).
  • Ett värde är ett JSON- värde (dvs. en sträng, ett tal, sant eller falskt, ett objekt, en array), eller ett JSON-LD- typat värde (dvs en sträng som lexikal form av värdet tillsammans med en typ, definierad av en XSD- bastyp eller mer allmänt en IRI ), eller ett JSON-LD- strukturerat värde (dvs. en uppsättning, en lista eller en språktaggad sträng).
  • En typ är en OWL- klass som är en underklass till antingen klasserna NGSI-LD Entity, NGSI-LD Relationship, NGSI-LD Property eller NGSI-LD Value som definieras i NGSI-LD-metamodellen. NGSI-LD fördefinierar ett litet antal typer, men är i övrigt öppen för alla typer som definieras av användare.

Som komplement till denna metamodell tillhandahåller NGSI-LD-informationsmodellspecifikationen också en ontologi över flera domäner som definierar nyckelkonstruktioner relaterade till rumsliga, tidsmässiga eller systemsammansättningsegenskaper hos entiteter.

Den flexibla informationsmodellen tillåter specifikation av vilken typ av enhet som helst. För att möjliggöra interoperabilitet mellan NGSI-LD-användare definieras standardiserade enheter i samarbete i Smart Data Models Program och görs tillgängliga på dess arkiv med en öppen källkodslicens.

Arkitektur

NGSI-LD-specifikationen består av en informationsmodell och ett API. API:et tillhandahåller funktioner för att stödja de arkitektoniska roller som beskrivs i det följande.

NGSI-LD Architecture Interactions

  • Context Consumer : En Context Consumer konsumerar NGSI-LD Entities från en Context Broker (eller möjligen direkt från en Context Source) med hjälp av Context Information Consumption-funktionerna i NGSI-LD API. Den kan hämta en specifik NGSI-LD Entity eller fråga relevant NGSI -LD Entiteter som använder synkrona förfrågningar. Den kan också prenumerera på relevanta NGSI-LD-entiteter och ta emot asynkrona meddelanden närhelst det sker ändringar i de begärda NGSI-LD-entiteterna.
  • Context Producer : En Context Producer skapar, uppdaterar och tar bort NGSI-LD Entities, NGSI-LD Properties och NGSI-LD Relationships i Context Broker med hjälp av Context Information Provision-funktionerna i NGSI-LD API.
  • Context Source : En Context Source gör NGSI-LD Entities tillgängliga via Context Information Consumption-funktionerna i NGSI-LD API. För att göra informationen upptäckbar för en kontextmäklare, registrerar den vilken typ av sammanhangsinformation den kan tillhandahålla med en registerserver med hjälp av kontextkällaregistreringsfunktionen i NGSI-LD API.
  • Kontextmäklare : En kontextmäklare fungerar som de primära åtkomstpunkterna till kontextinformation för kontextkonsumenter. NGSI-LD Entity-information kan lagras av Context Broker själv, om den har tillhandahållits av en Context Producer med hjälp av Context Information Provision-funktionerna i NGSI-LD API, eller om mäklaren kan begära är från Context-källor med Context Information Consumption funktionerna i NGSI-LD API. Context Broker aggregerar all NGSI-LD Entity-information relaterad till en begäran och returnerar det aggregerade resultatet till Context Consumer. I fallet med en prenumeration skickar den aviseringar närhelst det finns relevanta ändringar, eventuellt som ett resultat av att man tar emot meddelanden från kontextkällor. För att hitta kontextkällor som kan ha NGSI-LD-entiteter som är relevanta för en kontextkonsumentbegäran, använder kontextmäklaren funktionen för upptäckt av kontextkälla för NGSI-LD API:n implementerad av registerservern.
  • Registerserver : Registerservern lagrar kontextkällregistrering som tillhandahålls av kontextkällor med hjälp av kontextkällregistreringsfunktionerna i NGSI-LD API. Kontextkällasregistreringar innehåller information om vilken typ av kontextinformation en kontextkälla kan tillhandahålla, men inte faktiska värden. Typen av sammanhangsinformation kan tillhandahållas på olika granularitetsnivåer, allt från mycket detaljerad information, t.ex. vissa egenskaper eller relationer för en specifik NGSI-LD-enhet, till vilken information som helst från en specifik NGSI-LD-enhet, eller till den nivå som den kan tillhandahålla NGSI-LD Entiteter som har en viss Entity Type, möjligen för ett givet geografiskt område. Funktionen Context Source Discovery i NGSI-LD API gör att Context Broker (eller möjligen en Context Consumer) kan hitta kontextkällor som kan ha relevanta NGSI-LD Entities.

De arkitektoniska rollerna tillåter implementering av olika distributionsarkitekturer. I en centraliserad arkitektur finns det en central Context Broker som lagrar kontextinformationen från Context Producers. I en distribuerad inställning kan all kontextinformation lagras av kontextkällor. I en federerad arkitektur kan kontextkällor återigen vara kontextmäklare som gör aggregerad information från en lägre hierarkinivå tillgänglig. Dessa arkitekturer utesluter inte varandra, det vill säga en faktisk utbyggnad kan kombinera dem på olika sätt.

API

NGSI-LD Context Information Management API tillåter användare att tillhandahålla, konsumera och prenumerera på sammanhangsinformation i flera scenarier och involverar flera intressenter. Det möjliggör nära till realtidsåtkomst till information som kommer från många olika källor (inte bara IoT-datakällor), kallade Context Sources, samt att publicera den informationen genom interoperabla datapubliceringsplattformar.

Den tillhandahåller avancerade geo-temporala frågor, och den inkluderar prenumerationsmekanismer, för att innehållskonsumenter ska meddelas när innehåll som matchar vissa begränsningar blir tillgängligt.

API:et är utformat för att vara agnostiskt mot arkitekturen (central, distribuerad, federerad eller kombinationer därav), så att applikationer som producerar och konsumerar information inte behöver skräddarsys efter specifikationerna för det system som distribuerar/förmedlar kontextinformation för dem.

API-operationer omfattar:

  • Kontextinformationsoperationer , som handlar om tillhandahållande (skapa NGSI-LD-entiteter och uppdatera deras attribut), konsumtion (fråga NGSI-LD-entiteter) och prenumeration (prenumerera på specifik information, under specificerade begränsningar, för att meddelas när matchande enheter visas, bär den specificerade informationen).
  • Context Sources -operationer som rör registrering (gör en ny källa med kontextinformation tillgänglig i det övergripande distribuerade systemet genom att registrera den) och Discovery (frågar systemet om vilka sammanhangskällor som har registrerats, som erbjuder information av en specificerad typ).

Används

NGSI-LD initierades av partners i FIWARE-programmet och används främst av FIWARE open source-community, med stöd av FIWARE Foundation samt en mängd andra projekt och användare som nedan:

  • Connecting Europe Facility rekommenderar användning av FIWARE-kontextmäklaren med NGSI-LD
  • Living-in.eu-projektet rekommenderar användningen av NGSI-LD i deras gemensamma deklaration och deras tekniska åtaganden. Deklarationen har godkänts och undertecknats av 86 städer och offentliga förvaltningar från EU, och stöds av många fler företag och organisationer.
  • GSMA "IoT Big Data Framework Architecture" är baserad på NGSI-LD .
  • Fed4IoT EU-projektet, där det används som ett neutralt dataformat för att översätta mellan olika IoT-datarepresentationer
  • Den Thing'in grafbaserade digitala tvillingplattformen från Orange använder NGSI-LD som sin kärninformationsmodell. [ citat behövs ]

Historia

NGSI-LD är resultatet av en utveckling av kontextgränssnitt som startade som en del av "Next Generation Service Interfaces" (NGSI)-sviten publicerad av Open Mobile Alliance (OMA) 2012, som också är källan till akronymen NGSI. NGSI-sviten inkluderade NGSI-9 som Context Entity Discovery Interface och NGSI-10 som Context Information Interface. NGSI-standarden från OMA och dess intermediära utvecklingar förlitade sig på en klassisk Entity-attribute-value-modell och en XML-baserad representation. NGSI Context Interfaces anpassades av FI-WARE-projektet, som utvecklade plattformen för European Future Internet Public-Private-Partnership (PPP). OMA NGSI Context Interfaces fick en HTTP-bindning med en JSON-representation, kallad NGSIv1, som inkluderade både NGSI-9 och NGSI-10. Under loppet av FI-PPP utvecklades gränssnitten ytterligare till NGSIv2, som blev nyckelgränssnittet för FIWARE-plattformen. Efter slutet av FI-PPP 2016 blev FIWARE-plattformen kärnan i FIWARE Open Source Community som hanteras av FIWARE Foundation. Under 2017 skapades ETSI Industry Specification Group on cross-cutting Context Information Management (ETSI ISG CIM) för att utveckla Context Information Interface, vilket resulterade i skapandet av NGSI-LD. Begränsningarna för den ursprungliga informationsmodellen ledde till specifikationen av en bredare modell som härrör från egenskapsgrafer, som uttryckligen inkluderar relationer mellan enheter, i paritet med enheterna själva.

Se även

externa länkar

Implementeringar i mjukvaruprojekt med öppen källkod