"Parsed text" is een vooraf gedefinieerde eigenschap. Deze eigenschap is van te voren gedefinieerd (ook bekend als een speciale eigenschap) en komt met extra beheersprivileges, maar kan worden gebruikt net als elk andere door de gebruiker gedefinieerde eigenschap.
I
Impactmap Genk +
Impactmap Gent +
Impactmap van het project sterke authenticatie van Gent - GZG +
This is a property of type Text . +
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] .
De gegevensuitwisseling zal drie belangrijke diensten leveren:
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.
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.
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:
Catalogusdienst die een kader biedt voor het beheer van meta-informatie over bronnen,
Autorisatiedienst, die de autorisatie beheert om toegang te krijgen tot de bronnen
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 .
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
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:
Referenties
↑ https://www.iudx.org.in/
↑ https://docs.google.com/document/d/e/2PACX-1vS7TvNSuQrbWGwwKEvVHZpquGg5bWmyvEtKv0I9fFvyBDZFWtm4UdV1e6DLtzkX4IRaGPMhztMButbQ/pub
↑ https://docs.google.com/document/d/e/2PACX-1vQBG5blEcxzm_WUnwaWMFRW3jmfBo2VyG-SgK7Aacbw0YpEhR1i80ZOOMGzQG_PxH5IDNamVkVOu7C4/pub
↑ https://apidocs.iudx.org.in/
↑ https://github.com/rbccps-iisc/iudx-schemas
Mapping product inflow and outflow +
Resultaten van de bevraging over de doelstellingen die beleidsmakers koppelen aan mobipunten (project IoT-gestuurde mobipunten) +
Een informatie-architectuur beschrijft de inhoudelijke relaties en samenhang tussen toepassingen en gegevens onderling. Een informatie-architectuur maakt de relaties tussen informatie van een organisatie inzichtelijk. +
Doelgroep en doel
De doelgroep van deze deliverable is het lokaal bestuur.
Het doel van deze deliverable is om de informatienoden op toepassingen voor eindgebruikers (bijvoorbeeld dashboards, portaalsite, mobiele app, ...) in kaart te zetten.
Inleiding
De informatienoden zijn het resultaat van de Informatiearchitectuur . Met de informatiearchitectuur willen we informatie (inhoud, afbeeldingen, bestanden, ...):
Organiseren (wat komt waar) en Structureren (wat zetten we samen) zodat deze toegankelijk en terugvindbaar is en;
Duurzaam te labelen zodat deze beheersbaar blijft achter de schermen.
Sjabloon
De informatienoden worden uitgewerkt in een mindmap. Dit is een visuele representatie van welke data we waar gaan weergeven en wat de relaties zijn onderling.
Voorbeeld van een mindmap:
Aanpak bij gebruik van deze deliverable
Een schets van de informatienoden worden tijdens een business of data workshop opgesteld. Tijdens de workshop stellen we vragen om te achterhalen welke informatie we willen weergeven, welke informatie samen hoort en welke informatie goed zichtbaar moet zijn en waar we hem op de toepassing willen zien verschijnen. Er wordt ook gevraagd naar mogelijke technische benamingen om deze mee te nemen in de mindmap (Labelen en groeperen van informatie).
Na de workshop wordt een mindmap opgesteld. Deze deliverable bestaat uit slechts één versie en wordt gedeeld in een bewerkbaar formaat.
Gelinkte deliverables
Informatiemodel +
This is the "Initiatief" template.
It should be called in the following format:
{{Request
|field_request_status=
|field_initiatiefnaam=
|field_maturiteitstype=
|field_domein=
|field_sleutelwoord=
|field_locatie=
|field_actoren=
|field_partners=
|field_traject=
}}
Edit the page to see the template text. +