De eerste implementaties van slimme steden in India beginnen ter plaatse positieve resultaten op te leveren. Ze werden grotendeels onafhankelijk gecreëerd in verticale silo's, met een beperkte standaardisatie van software Componenten of hun interfaces of de onderliggende datamodellen. De gegevens die door een specifieke applicatie worden gecreëerd, zijn meestal enkel beschikbaar voor die applicatie en kunnen niet breder worden ingezet. Dit beperkt de mogelijkheid om bredere inzichten te verkrijgen uit de enorme gegevens die binnen elk project & afdeling worden gegenereerd, voor gebruik tussen verschillende belanghebbenden binnen de stad en in verschillende steden.

Om deze uitdagingen op te lossen, heeft MoHUA het initiatief genomen tot een onderzoeksproject onder leiding van Prof. Bharadwaj Amrutur van het Indian Institute of Science (IISc), Bangalore, getiteld "India Urban Data Exchange (IUDX)"[1], een open source softwareplatform dat steden in staat moet stellen het volledige potentieel van de enorme data die in onze smart cities worden gegenereerd te benutten.

Indian Institute of Science (IISc), Bangalore, werkt samen met een breed scala aan instellingen bestaande uit de industrie, overheidsinstellingen, start-ups, ondernemers, andere academies en onderzoeks Organisaties, om de eerste specificaties en referentie-implementatie van IUDX te ontwikkelen.

Overzicht

Om de volgende generatie op AI/ML gebaseerde toepassingen te ontwikkelen voor het leveren van nieuwe oplossingen en diensten op schaal, heeft IUDX een referentiearchitectuur[2] en technische specificaties[3] gecreëerd voor het blootleggen van gegevens (met name IoT-gegevens) van IT-systemen van verschillende afdelingen en externe Organisaties, met behulp van gemeenschappelijke API's[4] en gegevensmodellen[5].

IUDX high level overview

De gegevensuitwisseling zal drie belangrijke diensten leveren:

  1. Een catalogusdienst die een catalogus met meta-informatie over de verschillende datasets zal hosten, met informatie over de beheerder van de gegevens, het datamodel voor de gegevens, de API-eindpunten, de API-methoden, enz.
  2. Een autorisatiedienst die een data custodian (die verantwoordelijk is voor de data) in staat stelt de toegang tot hun datasets te reguleren. Beveiliging en privacy zijn door het ontwerp in deze architectuur opgenomen.
  3. Een optionele data-broker, die gestandaardiseerde IUDX-API's zal ondersteunen om toegang te krijgen tot de data.

Referentie architectuur

Scope

De Indiase standaard beschrijft de referentiearchitectuur voor het gegevensuitwisselingskader, de interfaces van de gegevensuitwisselings Componenten en de use cases die in dit ecosysteem worden ingeschakeld. Het beschrijft ook de verantwoordelijkheden van de verschillende belanghebbenden en hun interacties met andere belanghebbenden in het systeem. De norm beschrijft ook de high level architectuur van de volgende drie hoofd Componenten van de gegevensuitwisselingsdiensten:

  1. Catalogusdienst die een kader biedt voor het beheer van meta-informatie over bronnen,
  2. Autorisatiedienst, die de autorisatie beheert om toegang te krijgen tot de bronnen
  3. Resource Access Service, die een gestandaardiseerde manier biedt om toegang te krijgen tot bronnen.

Principes

De referentiearchitectuur en het ontwerp die in deze norm worden beschreven, is gebaseerd op de volgende principes:

  • Technologie-agnostisch
  • Betrouwbaarheid en schaalbaarheid
  • Privacy-by-design
  • Security-by-design
  • Consumentgericht
  • Consent-driven
  • Open API's voor interoperabiliteit
  • Transparantie door middel van gegevens

High Level Architectuur

De Data-uitwisseling bestaat uit de volgende interfaces:

  • Resource-interface
  • Autorisatie-interface
  • Discovery-interface
  • Management-interface
  • Authorisatie-interface
  • Identity-interface

Middelen, beheerd door een Provider, worden gehost op een of meer Resource Servers, en worden beschikbaar gesteld voor consumptie aan entiteiten via een beschrijving van de meta-informatie (zoals het formaat, de Provider, enz.), via een catalogus in de Data Exchange. De catalogus is zowel menselijk leesbaar als machinaal leesbaar.

OGC Services Architecture

De aanbieder registreert en beheert de metagegevens van zijn middelen en het bijbehorende toegangscontrolebeleid via de beheersinterface van de gegevensuitwisseling. De Provider kan gebruik maken van een helper-applicatie, zoals de ProviderApp. De meta-data van elke resource moet een app-ontwikkelaar helpen om het gebruik van resources te vergemakkelijken en zo nuttige applicaties voor de consument te creëren.

De App kan zich registreren bij de DataExchange om op de hoogte te worden gesteld van eventuele wijzigingen in de meta-data van de bronnen die voor de Consument van belang zijn. De App verkrijgt toestemming om de bronnen te consumeren via de autorisatie-interface door het verkrijgen van een Autorisatie Token.

Elk verzoek aan de bron van een aanbieder door een consumentenapplicatie zal worden gecontroleerd aan de hand van het bestaande toegangscontrolebeleid. Als er geen beslissing kan worden genomen, zal de Gegevensuitwisseling de Aanbieder en de Consument te coördineren om een toestemmingstransactie af te ronden en het Autorisatietoken te genereren. Het Autorisatietoken zal worden gebruikt om het toegangscontrolebeleid voor deze middelen bij te werken. Het Autorisatietoken zal door het systeem worden gelogd om de controleerbaarheid van de toestemmingsstromen te garanderen. De coördinatie tussen de aanbieder en de consument gebeurt buiten het kader van deze specificatie en kan worden opgebouwd met behulp van alle beschikbare berichttechnologieën, zoals SMS/OTP/EMAIL, enz.

De licentievoorwaarden voor de gegevens vallen ook buiten het toepassingsgebied van deze specificatie. De licentievoorwaarden vallen ook buiten het toepassingsgebied van deze specificatie. In de metagegevens voor de bron kan echter wel naar de licentie worden verwezen. Om te zorgen voor een betere consumentenervaring, kan de App-ontwikkelaar ook het volgende invoeren in een grondstoffenlicentieovereenkomst met de aanbieder. In dit geval kan de consument beschermd tegen het apart verkrijgen van toestemming, zolang de App Developer en de App zich te houden aan de licentievoorwaarden van de aanbieder.

Catalog Service

Op hoog niveau maakt de DX-catalogusdienst het volgende mogelijk:

  • Discovery of data resources: door het aanbieden van verschillende zoekmechanismen om de interessante bronnen te ontdekken. Bijvoorbeeld, geo-gebaseerd zoeken, tekst zoeken op meta-informatie, attribuut zoeken met een bepaalde waarde, enz.
  • Gemak van de consumptie van gegevens: door het verstrekken van links naar gegevensmodellen die de verschillende attributen van de gegeven bron beschrijven. Dit verbetert de interoperabiliteit van de gegevens en maakt het eenvoudiger om ze te integreren in verschillende toepassingen.
  • Semantische modellering van meta-informatie: Door gebruik te maken van gekoppelde gegevens om semantische contexten te bieden voor de attributen die meta-informatie beschrijven. Dit leidt tot een betere machineleesbaarheid, interpreteerbaarheid, operationele interoperabiliteit en maakt hergebruik van woordenschat uit andere gegevensmodelarchieven en taxonomieën mogelijk.
  • Gemak van toegang tot gegevens uit een bron: door formele beschrijvingen te geven van hoe toegang kan worden verkregen tot de gegevens uit een bron. Bijvoorbeeld, API-objecten om op REST gebaseerde bronnen te beschrijven, enz.

Catalog Datamodel

IUDX Data Catalog Information Model

De figuur vat het catalogus-informatiemodel samen.

  • De basislaag bestaat uit kern-attribuuttypes. Een attribuut zal in het algemeen een 'type' en 'value' hebben en kan andere meta-eigenschappen hebben om het attribuut aanvullend te beschrijven. Het 'type' identificeert het type kernattribuut en heeft een van de volgende waarden: "Eigenschap", "Relatie", "GeoProperty", "QuantitativeProperty" en "TimeProperty". De 'value' bevat de waarden die aan het attribuut zijn toegekend en kan variëren van eenvoudige objecten, zoals strings of getallen, tot complexe objecten, zoals 'GeoJSON' objecten, enz.
  • Gemeenschappelijke attributen, die noodzakelijkerwijs een van de kern-attribuuttypen uitbreiden, dienen om een specifieke betekenis en interpretatie te geven aan een attribuutwaarde. Er zijn gemeenschappelijke attributen gedefinieerd om veelgebruikte concepten in DX-catalogus-items vast te leggen. Verder zijn alle verplichte attributen in verschillende catalogusitems noodzakelijkerwijs afkomstig uit de gemeenschappelijke attribuutenset.
  • Een itemType wordt gebruikt om een semantische interpretatie te beschrijven en te geven aan een collectieve set van attributen in een item. Elk itemType specificeert een set verplichte attributen die moet worden opgenomen in een item van dit itemType en deze attributen behoren noodzakelijkerwijs tot de gemeenschappelijke attribuutset.
  • Een gegevensmodel beschrijft meta-informatie-attributen en hun syntactische structuur voor een bepaald toepassingsdomein. Het raamwerk van de catalogus maakt, met behulp van de concepten van gekoppelde gegevens, hergebruik van attributen uit andere domeinspecifieke vocabulaires mogelijk.


Merk op dat het definiëren van een specifiek gegevensmodel valt buiten het bestek van de catalogus. Echter, omwille van de consistentie, moeten de in de gegevensmodellen gedefinieerde attributen dezelfde algemene reeks volgen van regels, die later worden gespecificeerd, zoals die worden gevolgd voor DX-metagegevensattributen. De bedoeling is hier een robuust kader te specificeren dat het mogelijk maakt te specificeren, te hergebruiken en een consensus te bereiken voor domeinspecifieke gegevensmodellen.

De relaties tussen de objecten in de data catalogus kunnen als volgt worden weergegeven:

IUDX Data Catalog Information Model

Referenties