Deze pagina biedt een eenvoudige bladerinteractie voor het vinden van entiteiten met een eigenschap met een bepaalde waarde. Andere beschikbare zoekinteracties zijn de zoekpagina voor pagina-eigenschappen en de querybouwer.

Lijst van resultaten

• Voorbeeld 2 configuratie file data analyse  +
• Voorbeeld dynamische tekening  +
• WS4_cijfers_water  +
• WS4water_antwerpen  +
• Waarom repair data loggen?  +
• Wat is een repair café en hoe kan ik er een starten?  +
• Wat is het SHAREPAIR project?  +
• Water - overzicht traject  +
• Welke data standaard bestaat er in het repair landschap?  +
• Welkom_bij_de_Vlaamse_Open_City_Architectuur_(VLOCA)_Kennishub  +
• What is Open Data? - Coock Seminar 'Open city and its Citizens'  +
• Zoeken per thema  +
• broker  +
• categorie reference  +
• compute  +
• databroker  +
• definitie kolommen in data tabblad  +
• diagonal  +
• donut  +
• federation of donuts  +
• figuur VLOCA  +
• from OpenDei  +
• Voor meer informatie over de stad Mortsel verwijzen we door naar de Wikipedia pagina .  +
• Voor meer informatie over de stad Oostende verwijzen we door naar de Wikipedia pagina .  +
• Voor meer informatie over de stad Roeselare verwijzen we door naar de Wikipedia pagina .  +
• Voorbeeld aanvulling -- MaartenVanLoo ( overleg ) 16 jun 2021 15:41 (CEST)  +
• W3C Web of Things probeert de versnipperin … W3C Web of Things probeert de versnippering van het Internet of Things tegen te gaan, waardoor het gemakkelijker wordt om toepassingen te creëren zonder dat het nodig is om de uiteenlopende technologieën en normen van het ivd onder de knie te krijgen. Digital twins voor sensoren, actuatoren en informatiediensten worden gekoppeld aan consumptietoepassingen als lokale softwareobjecten met eigenschappen, acties en gebeurtenissen, onafhankelijk van de fysieke locatie van apparaten of de protocollen die worden gebruikt om toegang te krijgen tot die apparaten.</br> </br> Opmerking: het Web of Things is nauw verbonden met het werk van W3C op het Web of Data [1] .</br> </br> Web of Things Architecture [2] </br> Deze WoT Architecture specificatie beschrijft een abstracte architectuur voor het W3C Web of Things. Deze abstracte architectuur is gebaseerd op een set van eisen die zijn afgeleid van use cases voor meerdere toepassingsdomeinen, beide gegeven in dit document. Er wordt ook een set van modulaire bouwstenen geïdentificeerd waarvan de gedetailleerde specificaties in andere documenten worden gegeven. In dit document wordt beschreven hoe deze bouwstenen samenhangen en samenwerken. De WoT abstracte architectuur definieert een basisconceptueel raamwerk dat in kaart kan worden gebracht op verschillende concrete inzetscenario's, waarvan verschillende voorbeelden worden gegeven. De abstracte architectuur die in deze specificatie wordt beschreven, definieert echter zelf geen concrete mechanismen en schrijft geen concrete implementatie voor.</br> </br> WoT Principes </br> Een Thing is de abstractie van een fysieke of virtuele entiteit (bijvoorbeeld een apparaat of een kamer) en wordt beschreven door gestandaardiseerde metadata. In W3C WoT moet de beschrijvingsmetadata een WoT Thing Description (TD) zijn. Consumenten moeten in staat zijn om het TD representatieformaat te ontleden en te verwerken. Het formaat kan worden verwerkt via klassieke JSON-bibliotheken of een JSON-LD-processor. Het gebruik van een JSON-LD processor voor de verwerking van een TD maakt het bovendien mogelijk om de semantische verwerking, inclusief de transformatie naar RDF-drievoudigen, de semantische inferentie en het uitvoeren van de gegeven taken op basis van ontologische termen, waardoor de consument zich meer autonoom zou gedragen. Een TD is voorbeeldspecifiek (d.w.z. beschrijft een individueel Thing, niet soorten Thingen) en is de standaard externe, tekstuele (Web) representatie van een Thing. Er kunnen andere representaties van een Thing zijn, zoals een HTML-gebaseerde gebruikersinterface, gewoon een afbeelding van de fysieke entiteit, of zelfs niet-Web representaties in gesloten systemen.</br> </br> Things </br> Een Web Thing heeft vier architectonische aspecten: </br> </br> zijn Behavior, </br> zijn Interaction Affordances, </br> zijn Security Configuration </br> en zijn Protocol Bindings. </br> Het gedragsaspect (Bahavior) van een Ding omvat zowel het autonome gedrag als de handlers voor de Interaction Affordances. De Interaction Affordances bieden een model van hoe consumers kunnen communiceren met het Thing door middel van abstracte bewerkingen, maar zonder verwijzing naar een specifiek netwerkprotocol of gegevenscodering. De protocolbinding voegt de extra details toe die nodig zijn om elke Interaction Affordance in kaart te brengen bij concrete berichten van een bepaald protocol. In het algemeen kunnen verschillende concrete protocollen worden gebruikt om verschillende subsets van Interaction Affordances te ondersteunen, zelfs binnen een enkel Ding. Het veiligheidsaspect van een Ding vertegenwoordigt de mechanismen die worden gebruikt om de toegang tot de Interaction Affordances en het beheer van gerelateerde Public Security Metadata en Private Security Data te controleren.</br> </br> </br> WoT building blocks </br> De Web of Things (WoT) bouwstenen maken het mogelijk om systemen te implementeren die voldoen aan de abstracte WoT-architectuur.</br>De WoT-bouwstenen ondersteunen elk van de architectonische aspecten van een Thing.In de volgende figuur zijn de WoT-bouwstenen gemarkeerd met zwarte contouren. Veiligheid, een transversale zorg, is opgedeeld in publieke en beschermde private Componenten . De WoT Scripting API is optioneel en de Binding Templates zijn informatief.</br> </br> </br> Web of Things Description [3] </br> Dit W3C document beschrijft een formeel model en een gemeenschappelijke representatie voor een Web of Things (WoT) Thing Description. Een Thing Description beschrijft de metadata en interfaces van Things, waarbij een Thing een abstractie is van een fysieke of virtuele entiteit die interacties levert aan en deelneemt aan het Web of Things. Thing Descriptions bieden een set van interacties op basis van een kleine woordenschat die het mogelijk maakt om zowel diverse apparaten te integreren als diverse applicaties te laten samenwerken. Thing Descriptions zijn standaard gecodeerd in een JSON-indeling die ook JSON-LD-verwerking mogelijk maakt. Dit laatste biedt een krachtige basis om de kennis over de dingen op een machinebegrijpelijke manier weer te geven. Een Thing Description instantie kan worden gehost door de Thing zelf of extern worden gehost wanneer een Thing resource restricties heeft (bijvoorbeeld beperkte geheugenruimte) of wanneer een Web of Things-compatibele legacy-apparaat achteraf wordt uitgerust met een Thing Description.</br> </br> </br> [Category:Standaarden]</br> </br> Referenties </br> </br> ↑ https://www.w3.org/2013/data/ </br> </br> ↑ https://www.w3.org/TR/wot-architecture/ </br> </br> ↑ https://www.w3.org/TR/wot-thing-description/description/  +
• WAT IS FIWARE De FIWARE Foundation [1] … WAT IS FIWARE </br> De FIWARE Foundation [1] definieert FIWARE als volgt:</br>FIWARE is een samengesteld raamwerk van open source platform componenten om de ontwikkeling van slimme oplossingen te versnellen</br> Het framework van FIWARE bestaat uit marktklare open-source software, die componenten combineert die de verbinding met IoT mogelijk maken met context information Management en Big Data-services in de cloud. Daarnaast definieert het ook een standaard API voor databeheer en uitwisseling, evenals geharmoniseerde datamodellen. Het FIWARE framework is gericht op de automatisering van processen in de hele waardeketen. Maakt eenvoudige plug & play integratie met andere oplossingen en diensten mogelijk. Het biedt ook een marktplaats voor overdraagbare en interoperabele oplossingen.</br> De FIWARE verzameling van componenten wordt gebruikt door een groot aantal steden en projecten in en buiten Europa. (bijv. Eindhoven(NL), Santander(E), Montevideo(UR), Synchronicity , [ [1] ])</br> </br> FIWARE Foundation </br> Het FIWARE framework wordt beheerd door de FIWARE Foundation [2] Het promoot actief de FIWARE adoptie, ondersteunt de gemeenschap door gedeelde bronnen te bieden en valideert de FIWARE-technologieën.</br> </br> FIWARE componenten </br> De FIWARE-set van componenten richt zich op het verschaffen van context informatie voor slimme oplossingen.</br> </br> Slimme Oplossingen </br> Slimme oplossing zoals FIWARE het ziet, zijn geïntegreerde software componenten die een specifiek onderwerp aanpakken. De gebieden die de FIWARE Foundation identificeert zijn:</br> </br> slimme steden : oplossingen om een ​​stad leefbaarder te maken </br> smart agrifood: optimaliseer de productie op boerderijen door op een duurzame manier gebruik te maken van de modernste middelen; </br> slimme energie: oplossingen voor o.a. snelle integratie van gedistribueerde energiebronnen, gedecentraliseerde markten en Peer2Peer energie-uitwisselingen; </br> slimme industrie: automatisering en gegevensuitwisseling in fabricagetechnologieën (industrie 4.0). </br> Context Informatie </br> Het sleutelconcept dat FIWARE gebruikt, is context information . Context voegt tijd en locatie toe aan data, waardoor het mogelijk is om deze informatie te relateren aan andere bronnen en aan de omgeving. De basis softwarecomponent binnen FIWARE is de zogenaamde context broker .</br> </br> NGSI </br> Communicatie tussen en met FIWARE- componenten is gebaseerd op de NGSI RESTfull API . De huidige versie van deze interface NGSI-LD is een ETSI-standaard.</br> </br> FIWARE Catalogus </br> Gebaseerd rond de context broker heeft het FIWARE-ecosysteem een ​​groot aantal software- componenten gecreëerd. Sommigen van hen hebben de status Generic Enablers gekregen. Deze zijn gecontroleerd door middel van een uitgebreide set van Quality Assurance-tests. De componenten zijn onderverdeeld in de volgende categorieën:</br> </br> Core Context Management </br> Een context broker Generic Enabler is het belangrijkste en verplichte onderdeel van elk “Powered by FIWARE” -platform of -oplossing. Het maakt het mogelijk om context informatie op een zeer gedecentraliseerde en grootschalige manier te beheren.</br>Naast een aantal Context Broker-implementatie bevat het ook componenten om context informatie op korte of lange termijn op te slaan in een database:</br> </br> Interface met IoT, Robots En Systemen Van Derden </br> Er zijn een aantal generieke enablers beschikbaar die het gemakkelijker maken om te communiceren met het Internet of Things (IoT, internet der dingen), robots en systemen van derden om waardevolle context informatie te verzamelen of triggers te activeren als reactie op context updates. Deze componenten kunnen ondersteuning bieden voor het ophalen en verzenden van informatie naar protocollen zoals LWM2M, LoRaWAN, voor IoT-toepassingen, DDS2 voor robotica en andere.</br> </br> Context verwerking, Analyse En Visualisatie </br> Er zijn een aantal Generic Enablers beschikbaar die het gemakkelijker maken om context informatie te verwerken, analyseren of visualiseren met het doel het “slimme gedrag” te implementeren dat in elke applicatie wordt verwacht. Het bestaat uit applicaties voor het visualiseren van informatie, het toepassen van business intelligence op data en componenten voor het verwerken van events en media.</br> Daarnaast zijn er een aantal componenten voor beheer, publicatie en het genereren van inkomsten.</br>Een volledige lijst met componenten is hier te vinden [ [2] |catalogue]. Broncode voor deze componenten is beschikbaar op [ [3] ].</br> </br> FIWARE Organisatie </br> Naast de ondersteuning van de FIWARE software componenten is de FIWARE Foundation actief op een aantal gebieden:</br> </br> Outreach wereldwijd; verspreiden van FIWARE binnen en buiten Europa; </br> iHubs; hubs om FIWARE te promoten </br> Accelerators; ondersteuning van high-potential startups. </br> Het werkt ook nauw samen met Open And Agile Smart Cities (OASC) en TM Forum bij het definiëren van standaard datamodellen vanuit een slimme oplossing op basis van de NGSI-LD standaard.</br> </br> </br> ↑ https://www.fiware.org/about-us/ </br> </br> ↑ https://www.fiware.org/foundation/  +
• Waarom digitale hoppinpunten? Het samenb … Waarom digitale hoppinpunten? </br> Het samenbrengen van verschillende vervoersmiddelen op één fysieke locatie past perfect in een “overstapmodel” of het concept van "combimobiliteit". Daarbij willen we maatschappelijk een slimmere, performantere en ook meer duurzame en inclusieve bereikbaarheid bekomen. Wie vandaag de trein neemt kan dat in heel wat stations al ervaren. Het voor- en natransport zijn cruciaal om de trein als mobiliteitssysteem goed te laten werken. Sinds enkele jaren is met verschillende aanbieders van deelfietsen en steps onder de noemer micromobiliteit een enorm veel groter scala aan mogelijkheden ontstaan voor de zogenaamde “laatste kilometer”. En met de komst van allerlei apps en/of terminals die werken met betaalkaarten om bijvoorbeeld het slot van voertuigen te openen of je toegang tot vervoer te regelen is er nu ook controle op het correcte gebruik en betaling.</br> Voeg daarbij nog een app die je perfect kan vertellen waar je bent, die de verschillende vervoersopties in de buurt aanwezig weergeeft en die je ook de meest optimale route kan tonen tot je bestemming. De cirkel is zo rond voor de reiziger als "consument" van de mobiliteitsdiensten.</br> Dit model van fysieke overstapplekken of "hoppinpunten" met verschillende vervoersopties en daarbij horende "digitale infrastructuur" waarmee je deze opties kan consumeren, maakt het effectief mogelijk om ook zonder wagen slimmer - en soms zelfs sneller en goedkoper - je van A naar B te verplaatsen.</br> </br> Hét werkpunt: data delen </br> Op zich lijkt deze digitalisering van het mobiliteitsaanbod al aardig te lukken: je kan trein- en bustickets kopen met een app of met je bankkaart aan een terminal. Je kan ook de dienstregeling raadplegen op een website of via een app. Je kan een slot van een fiets of een wagen openen met een app of een kaart. Het is evenwel wanneer alle data moet worden samengevoegd om geïntegreerde reisinformatie en -planning aan te bieden op zo'n overstapplek dat het nog niet loopt zoals het zou moeten. Of wanneer de data moet worden gedeeld met overheden of andere partijen die ze zouden kunnen gebruiken voor analyses of optimalisatie.</br> Iedere service provider, publiek of privaat, heeft voor zich wat hij of zij nodig heeft voor de eigen dienst, maar is bang om het te delen. Is het de vrees om klanten of controle te verliezen? Of is het een bezorgdheid ten aanzien van de klant? Want klein of groot, alle aanbieders zijn zeer gevoelig als het gaat om hun klanten, wat die denken over de service en wat ze effectief met de service doen.</br> De competitie die speelt tussen aanbieders van mobiliteit is reëel en moet zeker worden erkend. Maar voor de burger is net die competitie tussen de transportmodi interessant, zeker voor diegenen die zich zonder wagen willen verplaatsen. En ook voor de stad of gemeente is een divers aanbod béter want goedkoper en met méér marge om te onderhandelen en te zoeken naar de juiste oplossing op de juiste plaats.</br> De service provider heeft er alle belang bij dat zijn dienst veel wordt geconsumeerd, en dus dat er veel en trouwe klanten zijn. Het model van de nieuwe mobiliteit draait in grote mate om een geïntegreerd aanbod van verschillende diensten met een grote keuzevrijheid voor de reiziger. Hoe beter die individuele diensten geconnecteerd zijn en gebruikt worden, hoe meer ze elkaars gebruik gaan stimuleren. Je kan het zien als een winkelstraat: hoe meer aantrekkelijke winkels dicht bij elkaar in de winkelstraat, hoe meer mensen er op bezoek komen en hoe meer er wordt geconsumeerd.</br> </br> De burger die beslist? </br> Dus naast een divers aanbod aan vervoersopties is data delen echt een belangrijke voorwaarde om de digitalisatie van het mobiliteitsaanbod via hoppinpunt te laten slagen. De vraag is dan, wie beslist er over de data?</br> Nu wordt de vraag om data altijd gesteld aan de leverancier van de dienst, maar waarom de vraag niet stellen aan de mensen/de reiziger zélf? De data over de verplaatsingen van reizigers komt immers in de eerste plaats die reizigers zélf toe. Het delen van data over verplaatsingen moethun keuze kunnen zijn. Dat een bedrijf met een mobiliteitsaanbod de data gebruikt om haar dienst te verbeteren is legitiem, dat het zich beschermt tegen concurrenten in een competitieve markt is logisch. Maar de consumenten van die diensten zouden zélf moeten kunnen beslissen om hun verplaatsingsdata te doneren aan de stad of een dienstverlener die haar kan helpen met analyses om betere diensten te bekomen. Laat dan duizend bloemen bloeien en de spelers groot en klein hun aanbod afstemmen op elkaar zodat iedereen er beter van wordt. Elke speler zal immers gedreven worden naar efficiëntie en waardecreatie en zijn plaats vinden in het overstapmodel.</br> Van het allergrootste belang is dan dat de mensen/burgers hun data (i) op een transparante en gestandaardiseerde wijze ter beschikking stellen, (ii) dat ze ze in vertrouwen kunnen afgeven aan wie ze gebruikt, (iii) dat ze ook zicht krijgen op wat er uiteindelijk met de analyse van de data gebeurt en (iv) dat ze in ruil een verbeterde dienstverlening krijgen.</br> </br> De steden en gemeenten aan zet </br> Hoppinpunten hebben uiteraard altijd een fysieke aanwezigheid in de publieke ruimte. In het bijzonder op plaatsen waar we diverse activiteiten zoals winkels, kantoren, scholen, gezondheidszorg, sport, cultuur en ontspanning zich concentreren en dus veel mensen en goederen samenkomen is het meer noodzakelijk om dat te organiseren. Typisch dus het centrum van grotere steden. Zij zijn dan ook de voortrekkers vandaag in de uitrol van deze plekken en de bijhorende digitalisatie. Het is immers niet alleen de consument die digitale toegang nodig heeft, maar ook de stad kan onmogelijk evalueren en plannen zonder die data. Hoe groter de drukte, hoe belangrijker het wordt om alles in goede banen te leiden en hoe belangrijker het is om te weten wie zich wanneer en hoe verplaatst.</br> Deze regisseursrol is de steden op het lijf geschreven: ze wedijveren met elkaar op een positieve manier om het meest aantrekkelijk te zijn voor hun eigen inwoners, voor bedrijven die zich er vestigen en voor bezoekers die horeca en winkels bezoeken, die op hun beurt zorgen voor een bruisende stad. Ook kleine steden en gemeenten zoeken naar hun mogelijkheden in dat aanbod, want ook zij wedijveren met elkaar en met de andere steden - met een wens om het dorp klein maar aantrekkelijk te houden. En ook daar zie je dus dat men het centrum wil opwaarderen en dus de publieke ruimte slim wil transformeren om aantrekkelijker te zijn - lees: niet alleen maar parking. En ook die dorpen hebben op hun schaal nood aan data en afgeleide informatie. Werkt die deelwagen hier nu wel of niet? Wie gebruikt de uitleen/deelfietsen? Of het nu een grote stad is of een klein dorp, vanuit een andere perspectief stelt men dezelfde vragen.</br> </br> Het bouwplan: de informatiearchitectuur van een mobipunt </br> Om gestructureerd en professioneel te werken aan hoppinpunten is er een bouwplan nodig. Dat is zo bij het bouwen van fysieke infrastructuur, maar ook bij initiatieven van digitalisatie. De "digitale informatie architectuur" van de hoppinpunten die in het kader van dit VLOCA traject zal worden opgesteld, moet ervoor zorgen dat data over de diensten en wie ze waar en wanneer consumeert op een veilige, gestructureerde en doelgerichte manier wordt ontsloten:</br> "Veilig" omdat we met persoonlijke data werken. Zelfs zonder iemands identiteit kan je met voldoende mobiliteitsdata heel wat persoonlijke informatie over iemand verwerven, dus moet dat veilig gebeuren, in lijn met de geldende regelgeving rond gegevensbescherming.</br> "Gestructureerd ” of ook wel “FAIR" genoemd. FAIR data voldoen aan principes van vindbaarheid, toegankelijkheid, interoperabiliteit en herbruikbaarheid. Werken met FAIR data biedt zekerheid en duidelijkheid voor alle betrokken partijen: voor diegene die data moeten leveren beschrijven deze FAIR data principes hoe data best georganiseerd en gestructureerd worden. Voor diegene die data consumeren geven FAIR principes meer duidelijkheid over wat men van de data mag verwachten.</br> "Doelgericht" omdat zowel burgers als service providers duidelijkheid moet worden gegeven over wie wat met "de data" kan, mag en gaat doen. Als duidelijk blijkt dat het doel van data delen gemeenschappelijk is, namelijk alle services te doen floreren naast en met elkaar en daardoor een betere en efficiëntere mobiliteit te organiseren, alleen dan kan de achterdocht verdwijnen en plaats maken voor samenwerking, ook binnen een commerciële en competitieve setting.  +
• Wat is Citizen Science? Citizen science … Wat is Citizen Science? </br> Citizen science (ook wel: burgerwetenschap) is wetenschappelijk onderzoek uitgevoerd door niet-professionele wetenschappers (burgerwetenschappers). De burgens voeren hierbij taken uit als het tellen van diersoorten, een staalname in de de plaatselijke rivier nemen, een weerstation aan of rond het huis plaatsen, etc... Vaak wordt er hierbij samengewerkt met professionele wetenschappers. Citizen science is een zeer waardevolle wetenschappelijke onderzoeksmethode. Het draagt niet alleen bij tot betere wetenschappelijke kennis, maar het kan ook een waardevolle bijdrage leveren aan de sociale cohesie en/of onderwijs.</br> </br> Twee hands-on draaiboeken </br> VLOCA stelt 2 hands-on en technische draaiboeken ter beschikking om op een goede manier van start te gaan met je verzamelde data. De focus lig zoveel mogelijk op gratis of goedkope open-source oplossingen:</br> </br> Hoe maak ik zelf een databank aan voor mijn citizen science project </br> H oe publiceer ik de data van mijn citizen science project </br> </br>Uiteraard zijn er meer stappen te nemen om tot een volledige data flow te komen. Mogelijks wil je een bepaald data standaard volgen, de data door statistische programma's valideren, of de data in een dashboard visualiseren. In de volgende paragraaf kan je de zoektocht naar zulke oplossingen verder zetten.</br> </br> Meer weten? </br> SciVil (Citizen Science Vlaanderen) heeft een waaier aan gedetaileerde handleidingen om alle stappen in het citizen science process tot een goed einde te brengen:</br> </br> Data charter: https://www.scivil.be/en/book/data-charter-and-guide-citizen-science </br> Citizen science voor de lokale overheden: https://www.scivil.be/en/book/citizen-science-local-government </br> Citizen science en communicatie: https://www.scivil.be/en/book/communication-citizen-science </br> Citizen science projecten in Vlaanderen: https://www.scivil.be/en/projectsanderen: https://www.scivil.be/en/projects  +
• Wat is Semi Structured Data? Semi Structured data is een component van de Data capture bouwlaag.  +
• Wat is een Knowledge Graph Een knowledge … Wat is een Knowledge Graph </br> Een knowledge graph vertegenwoordigt een verzameling onderling verbonden beschrijvingen van entiteiten - real-world objecten, gebeurtenissen, situaties of abstracte concepten. Om deze abstracte definitie te illusteren hier een diagram van een knowledge graph [1] van boeken en hun auteurs.</br> </br> © Enterprise Knowledge LLC</br> In een dergelijk model hebben de beschrijvingen een formele structuur, waardoor zowel mensen als computers ze op een efficiënte en ondubbelzinnige manier kunnen verwerken.</br>De Entiteitsbeschrijvingen dragen bij aan elkaar en vormen een netwerk, waarbij elke entiteit een deel vertegenwoordigt van de beschrijving van de entiteiten die daarmee verband houden. b.v. Oscar Wilde was geboren in Ierland .</br> In de context van Smart Cities, deze knowledge graph is geordend volgens naar de relevante domeinen (bv. luchtkwaliteit), en specifieke relevante entiteiten (bv. locatie, PM10 waarde)</br> </br> Sleuteleigenschappen </br> Een knowledge graph combineert kenmerken van verschillende gegevens paradigma's en kunnen worden begrepen als een:</br> </br> Database , omdat de gegevens kunnen worden opgevraagd via gestructureerde zoekopdrachten; </br> Graaf [2] , omdat het kan worden geanalyseerd als elke andere netwerkgegevensstructuur; </br> Kennisbank , omdat de gegevens erin een formele betekenis(semantiek) hebben, die kan worden gebruikt om de gegevens te interpreteren en nieuwe feiten af te leiden. </br> Wanneer formele semantiek wordt gebruikt om de gegevens van een knowledge graph uit te drukken en te interpreteren, zijn er een aantal representatie- en modelleerinstrumenten:</br> </br> Klassen </br> Meestal bevat een entiteitsbeschrijving een classificatie van de entiteit met betrekking tot een klassehiërarchie. Bij algemene nieuws- of bedrijfsinformatie kunnen er bijvoorbeeld klassen Persoon, Organisatie en Locatie zijn. Personen en Organisaties kunnen een gemeenschappelijke superklasse Agent hebben. Locatie heeft meestal tal van subklassen, b.v. Land, bevolkte plaats, stad, enz. Het begrip klasse wordt ontleend aan het objectgeoriënteerde ontwerp, waarbij elke entiteit tot precies één klasse behoort te behoren.</br> </br> Relaties </br> De relaties tussen entiteiten zijn meestal gekenmerkt met typen, die informatie geven over de aard van de relatie, b.v. vriend, familielid, concurrent, etc. Relatietypen kunnen ook formele definities hebben, b.v. dat ouder-van een omgekeerde relatie is van kind-van, het zijn beide speciale gevallen van familielid van, wat een symmetrische relatie is. </br> </br> Categorieën </br> Een entiteit kan worden geassocieerd met categorieën, die een bepaald aspect van zijn semantiek beschrijven, b.v. “Openbaar Vervoer” of “19e eeuwse componisten”. Een boek kan tegelijkertijd tot al deze categorieën behoren: "Boeken over Afrika", "Bestseller", "Boeken van Italiaanse auteurs", "Boeken voor kinderen", enz. Vaak worden de categorieën beschreven en gerangschikt in een hierarchische ordening(taxonomie)</br> </br> Vrije tekst </br> Het is mogelijk ‘mensvriendelijke tekst’ toe te voegen om de intenties voor de entiteit verder te verduidelijken en het zoeken te verbeteren.</br> </br> Ontologieën </br> Een Ontologie kan beschouwd worden als de abstracte definitie van een knowledge graph, op basis van dewelke nieuwe knowledge graphs kunnen aangemaakt worden. Het dient als een formele definitie tussen de ontwikkelaars van de knowledge graph en zijn gebruikers. Een gebruiker kan een ander mens zijn of een softwaretoepassing die de gegevens op een betrouwbare en nauwkeurige manier wil gebruiken. Het zorgt voor een gedeeld begrip van de gegevens en de betekenis ervan. In het bovenstaande voorbeeld kan de ontologie als volgt worden gedefinieerd</br> </br> © Enterprise Knowledge LLC</br> </br> </br> ↑ http://enterprise-knowledge.com/whats-the-difference-between-an-ontology-and-a-knowledge-graph </br> </br> ↑ https://nl.wikipedia.org/wiki/Grafentheorie  +
• Wat is een data broker Een data broker s … Wat is een data broker </br> Een data broker slaat geen data op (by default); het verzamelt informatie uit verschillende bronnen; verwerkt het om het te verrijken, te verbeteren of te analyseren; en kan de data in licentie geven aan andere Organisaties . Data brokers kunnen ook rechtstreeks een licentie voor de gegevens van een andere organisatie geven of de gegevens van een andere organisatie verwerken om betere resultaten te behalen. Gegevens worden doorgaans benaderd via een Application Programming Interface (API) en hebben vaak betrekking op abonnementsovereenkomsten. Gegevens worden doorgaans niet 'verkocht' (d.w.z. het eigendom ervan overgedragen), maar worden in licentie gegeven voor bepaald of beperkt gebruik. (Een data broker wordt ook wel een information broker, syndicated data broker of information product supplier genoemd.)</br>Een data broker is dus nodig om data te delen tussen verschillende rollen in het ecosysteem zoals data producent, consument, prosument, model producent, city administratie, ... waarbij deze rollen "verifieerbare data organizaties" zijn. Een Data Broker treedt dus op als een "middle man" tussen data producenten en consumenten.</br> </br> </br> Data Marketplace </br> Vaak vervult een Data Broker ook de rol van data marketplace. Deze monetariseert de informatie die het doorgeeft aan de hand van een aantal modellen.</br>Voorwaarden om data af te nemen van een data broker die fungeert als marktplaats zijn bv:</br> </br> pay-per-use: gebruikers moeten betalen voor de gegevens die ze gebruiken </br> abonnement: gebruikers betalen een vast bedrag </br> geven en nemen: bebruikers kunnen de gegevens gratis gebruiken als ze ook gegevens aan de makelaar verstrekken. </br> Data Catalogus </br> Aangezien een data broker mogelijk een groot aantal gegevenstypen kan bedienen, moet er een methode zijn om dit door een klant doorzoekbaar te maken. Hiervoor is een datacatalogus nodig. Deze catalogus biedt gebruikers een gestructureerd overzicht van de informatie-elementen. Aangezien de gegevens doorgaans gestructureerd zijn en onderling gerelateerd zijn. Voorbeelden hiervan zijn luchtkwaliteitsgegevens en weergegevens. Voor beide is het van belang dat duidelijk is wanneer en voor welke locatie ze zijn geregistreerd. Deze catalogus wordt vaak de knowledge graph van de broker genoemd.</br> Naast de feitelijke gegevens bevat de knowledge graph ook gegevens die de gegevens beschrijven (bijv. Bron, eigenaar). Dit wordt metadata genoemd.</br>In het kader van VLOCA is de knowledge graph gebaseerd op de smart city domeinen </br> </br> Data Access </br> Een data broker moet niet alleen de toegang van een user regelen, maar moet de toegang tot de gegevens die hij bedient beheren; de toegangsbeheer moet fijnmazig zijn: tot welke gegevenselementen (bv. luchtkwaliteit) een klant toegang heeft, maar ook eventueel zijn toegang beperken tot bepaalde geografische regio's.</br>Bovendien moet het beheren hoe de gegevens worden gebruikt (datasoevereiniteit). Een klant die de gegevens gratis ontvangt voor bijvoorbeeld veiligheidsredenen mag deze niet opslaan voor historische analyse.</br> </br> Schaalbaarheid </br> Een data broker moet potentieel grote hoeveelheden data leveren aan users/clients. Gegevens die mogelijk afkomstig zijn van diverse, geografisch ver verwijderde bronnen. Een data broker moet daarom schaalbaar zijn door het ondersteunen van "federation": de data broker zal niet één instantie zijn, maar een gedistribueerde set van data broker, die naar behoefte kan worden geschaald.</br> </br> Security </br> Toegangscontrole is slechts een onderdeel van het beveiligen van een data broker. Een Data broker moet ook ervoor zorgen dat de gegevens op een veilige manier worden overgedragen. Ook zijn de gegevens die via de gegevensmakelaar worden geïnjecteerd afkomstig zijn van een vertrouwde bron. Daarom heeft een data broker fijnmazige mechanismen nodig om te garanderen dat de data wordt aangeboden betrouwbaar is en wordt gecommuniceerd met vertrouwde partijen.et vertrouwde partijen.  +
• Wat is een sensor? Een sensor is een onderdeel van een groter IoT systeem, dat instaat voor het meten van een bepaald fenomeen. Een sensor is een component van de Data capture bouwlaag.  +
• Wat is er nodig om 24/7 dienstverlening toegankelijk te maken voor alle burgers?  +
• Wat zijn de belangrijkste noden voor jullie bestuur om 24/7 producten en documenten beschikbaar te stellen?  +
• WaterML 2.0 is een standaard informatiemod … WaterML 2.0 is een standaard informatiemodel voor de weergave van waterwaarnemingsgegevens, met de bedoeling de uitwisseling van dergelijke gegevensreeksen tussen informatiesystemen mogelijk te maken. Door het gebruik van bestaande OGC- Standaarden is het bedoeld als een interoperabel uitwisselingsformaat dat kan worden hergebruikt om te voldoen aan een reeks eisen op het gebied van uitwisseling, waarvan sommige later in dit document worden beschreven.</br> [[Open Geospatial Consortium (OGC) | Overzicht van OGC Standaarden ›]][[Open Geospatial Consortium (OGC) | Overzicht van OGC Standaarden ›]]  +
• We usually ventilate our homes by opening … We usually ventilate our homes by opening windows or by using automatic ventilation but is this incoming air really that fresh? Or do we only make it worse by bringing in polluted outdoor air? Smart ventilation controlled by indoor and outdoor air quality, air purification in ventilation systems or in coatings on walls and windows, green facades that purify incoming air, a network of sensors that measure air quality online, ... The possibilities for the improvement of Indoor Air Quality (IAQ) are numerous and diverse but until now only rarely applied in practice. This workshop will define the problem and discuss the most important indoor pollutants, give an overview of what to measure and how to do it and pitch several technologies that can aid to purify indoor air.</br> Date: Tuesday April 20 th 2021, 10:00 - 12:00</br> Registration: https://share.hsforms.com/1IgRlXOjbTluP1nQTrKC7Ww42q9f </br> Registered participants will receive the conference-link a few days before the</br>meeting.</br> </br> </br> Agenda (2h online event) </br> 10:00 - 10:05 </br> Intro, Linus De Roo (UAntwerpen) </br> </br> 10:05 - 10:50 </br> Sources of indoor pollution and what/how to measure it, Marianne Stranger ( VITO ) </br> </br> 10:50 - 11:15 </br> CO2 sensing and analytics in smart buildings, ​ Valerio Panzica La Manna ( IMEC -NL)​​ ​</br> Presentation: </br> </br> </br> 11:15 - 11:45 </br> Air purification technologies, Linus De Roo (UAntwerpen) ​</br> Presentation: </br> </br> </br> 11:45 - 12:00 </br> Q&A</br> You can watch this workshop on Youtube here on Youtube here  +
• Welke noden zien jullie bij samenwerking met andere bestuurslagen voor het aanvragen en ophalen van documenten?  +
• Welke veiligheids- en regelgeving- uitdagingen moeten we aanpakken bij de overdracht van documenten en artikelen buiten kantooruren?  +
• Wereldwijd netwerk van Repair Café international (bron: https://www.repaircafe.org/bezoeken/ )  +
• Werkwijze Deze VLOCA kennishub is gebase … Werkwijze </br> Deze VLOCA kennishub is gebaseerd op een Semantisch MediaWiki platform. Hier bekijken we hoe het co-creatieproces in de praktijk wordt uitgerold. </br> Een goed review proces is essentieel om de VLOCA kwaliteitsdoelstellingen te bereiken. </br>VLOCA heeft immers als doel een kwalitatieve kennishub uit te bouwen. </br>Het VLOCA coördinatieteam van ABB , IMEC en VITO heeft sterke aandacht voor ongewenst digitaal vandalisme of pseudo-kennis, zodat de pure co-creatie tussen steden en gemeenten, bedrijven, burgers en kennisinstellingen steeds centraal blijft staan. </br> Tevens wordt VLOCA het neutrale referentiekader in Vlaanderen, los van commerciële belangenvermenging. </br>We nodigen leveranciers van Smart City oplossingen uit om een architectuur of Standaarden voorstellen die aligneren met de basiprincipes zoals interoperabiliteit en open Standaarden en de geest van VLOCA volgt. </br> Op deze Mediawiki pagina wordt het VLOCA review process geduid. </br> Hoe pagina's aanmaken en opmaken vind je op deze pagina terug. </br> </br> Registratie als deelnemer of stakeholder </br> Heb je interesse om op de hoogte te blijven van VLOCA ? Graag houden we je op de hoogte. </br>Wil je actief deelnemen ? Nog beter !</br> Vul dan als eerste stap op het VLOCA portaal het contactformulier in. </br>Een lid van het VLOCA kernteam neemt dan contact op met je om elkaars verwachtingen te bespreken. </br> Na dit eerste contact creëren we samen je account op de VLOCA kennishub en kan je mee starten in het co-creatie traject.</br> </br> Een aanvraag indienen </br> Een aanvraag tot co-creatie rond een initiatief kan worden ingediend via het daartoe voorziene formulier . Er wordt gevraagd enkele specifieke velden in te vullen over het initiatief en aan te geven of het gaat om een idee, een project, een proof of concept of een voorstel tot architecturale standaardisatie. </br> Eens je aanvraag geregistreerd is, kan je de status opvolgen : </br> </br> Geregistreerd : de aanvraag is geregistreerd, maar nog niet behandeld door een reviewer. </br> In behandeling : de aanvraag is in behandeling. </br> Co-creatie : het co-creatieproces voor dit initiatief is gestart. </br> Aan de hand van het formulier wordt een pagina aangemaakt waarbij een aantal semantische eigenschappen voorgedefinieerd zijn waarmee we de VLOCA kennishub verder zullen vormgeven. Je kan via de wiki "edit" functionaliteit dan gemakkelijk verder de inhoud bewerken of schema's of figuren opladen. </br> </br> Review process </br> Op de kennishub onderscheiden we 2 verschillende rollen voor geregistreerde gebruikers. Anonieme gebruikers hebben enkel leesrechten op de kennishub. Geregistreerder gebruikers zijn ofwel reviewer, of contributor : </br> </br> contributor  : Contributors leveren een bijdrage aan het platform door het registreren van aanvragen, het editeren en toevoegen van pagina's en het deelnemen aan de discussies. Contributors verkrijgen een account en toegang tot de kennishub door via het VLOCA portaal te registreren. </br> reviewer  : Reviewers zijn verantwoordelijk voor het nakijken en goedkeuren van page edits en het begeleiden van contributors in het aanleveren van kwalitatieve content. Reviewers worden geselecteerd op basis van neutraliteit en bevestigde expertise. </br> Bijdragen aan de kennishub werkt via het systeem van approved revisions . Bij het registreren van een aanvraag tot co-creatie rond een initiatief via het aanvraag formulier , wordt op basis van de ingevulde velden en secties een Mediawiki pagina aangemaakt. </br> Contributors zorgen voor de content, die na een goedkeuring door een reviewer als "approved revision" geldt. De revisies die gemarkeerd zijn als "approved revision" zijn voor iedereen leesbaar. </br> Consensus m.b.t. welke pagina geldt als goedgekeurde versie, wordt verkregen op de discussiepagina, waaraan contributors en reviewer kunnen bijdragen. In essentie is deze discussie vrij. </br> </br> Discussion pagina's </br> Als contributor is het mogelijk om deel te nemen aan de discussies voor elke pagina. Klik hiervoor op de Overleg tab. Op de discussie pagina's kan je jouw input toevoegen door de relevante topic te editeren of een topic toe te voegen. Hiervoor is een "Kopje toevoegen" tab voorzien. We vragen hierbij wel een zekere etikette aan de dag te leggen : </br> </br> Onderteken altijd je posts met een signature, hiervoor is een knop voorzien in de toolbar bovenaan het editeerveld, of je kan volgende tag invoegen : --~~~~ </br> Editeer nooit iemand anders z'n post, maar reageer via aparte posts en gebruik indentatie indentatie </br> Meer informatie over het gebruik van Overleg Pagina's is te vinden bij wikipedia [1] en [2] </br> </br> Co-creatie proces </br> Hier wordt een verdere beschrijving opgenomen van het co-creatie traject.</br> </br> OSLO methodiek: OSLO staat voor Open Standaarden voor Linkende Organisaties </br> De Vlaamse overheid zet in op een eenduidige standaard voor de uitwisseling van informatie. Het is de bedoeling om te zorgen voor meer samenhang en een betere vindbaarheid van data. Op die manier kan iedereen de gegevens makkelijker gebruiken. OSLO staat voor Open Standaarden voor Linkende Overheden ( OSLO ), een initiatief uit 2012 opgestart door de Vlaamse ICT-organisatie (V-ICT-OR). Hier werd de basis gelegd voor een open semantische informatiestandaard.</br> Met OSLO zet informatie Vlaanderen samen met haar partners versterkt in op semantische interoperabiliteit. Het standaardiseren van de betekenis van informatie is essentieel om het Vlaanderen Radicaal Digitaal principe ‘vraag niet wat je al weet’ te realiseren. Daarnaast zijn semantische Standaarden een belangrijke hefboom voor de interbestuurlijke dialoog en hergebruik van informatie door de private sector.</br> Op 31 maart 2017 werden de resultaten van het project OSLO opgeleverd op een publieke informatiedag. De vocabularia en applicatieprofielen die in dit project werden ontwikkeld in co-creatie met Vlaamse administraties, lokale besturen, federale partners, de Europese Commissie en private partners (88 auteurs) werden er aan een breed publiek voorgesteld.</br> Meer informatie over OLSO vind je op de website van de Vlaamse overheid </br> </br> Het VLOCA proces </br> Alignering: </br> Trajecten (initiatieven) geven input op de kennishub via een registratie. Deze input wordt door [[ IMEC ]]/ VITO / ABB gereviewed met input op VLOCA principes en concepten.</br> Projectidentificatie: </br> Aan de hand van o.m. live workshops analyseert het consortium [[ IMEC ]]/ VITO / ABB samen met initiatiefnemers het thema en verschillende principes binnen het project/initiatief. Deze projectidentificatie verloopt via bestaande netwerken zoals Smart Flanders, VVSG, … Daarbij worden andere belanghebbenden/stakeholders verder geïnventariseerd en wordt een procesplan samen met de initiatefnemers opgemaakt. </br> Consolidatie, goedkeuring en finalisering: </br> Het VLOCA proces wordt afgerond in afstemming met OSLO waarbij Standaarden en draaiboeken met bijhorende rollen en verantwoordelijkheden worden vastgelegd.</br> </br> </br> ↑ https://nl.wikipedia.org/wiki/Wikipedia:Overlegpagina </br> </br> ↑ https://nl.wikipedia.org/wiki/Wikipedia:Wikiquette  +
• What are the OSLO principles - COOCK Workshop - Open City and its Citizens  +
• Wie is AIOTI AIOTI is een Europese organ … Wie is AIOTI </br> AIOTI is een Europese organizatie opgericht vanuit de Europese Commisssie in 2015 met als doel om de dialoog en interactie tussen Europese IoT spelers te versterken, en zo bij te dragen tot een dynamische Europees IoT ecosysteem om de snelheid van IoT adoptie te vergroten.</br> </br> Enkele recente IoT & smart city inzichten </br> Deze 2 blogs geven een mooie evolutie van IoT-enabled steden en hun uitdagingen in de laatste 2 jaar :</br> In deze blog [1] een beschrijving gegeven van IoT-enabled cities met 3 prioriteiten voor (2018)</br> </br> Cross-domein (economisch schaalbare) toepassingen zullen essentieel zijn voor een duurzame verdere ontwikkeling van IoT binnen slimme steden </br> De industrie moet oplossingen brengen voor IoT platformen om data schaalbaar uit te wisselen </br> IoT platformen moeten schalen voor stream processing (inclusief video) </br> En meer recent [2] (2020) werden volgende inzichten gegeven ivm IoT-enabled smart cities en hun state-of-the-art:</br> </br> Data delen en integratie zijn de belangrijkste uitdagingen die moeten opgelost worden door standaard Organisaties en regulatoren. Voorbeelden zijn SAREF (een ontologie voor het voorstellen van kennis over slimme toepassingen) en NGSI-LD (een standaard API voor het delen van data verzamelingen) </br> Veerkrachtige steden moeten het gat tussen IoT en publieke veiligheid dichten </br> Kunstmatige Intelligentie moet binnen slimme steden ethisch zijn en rekening houden met de sociale impact </br> Stedelijk "generatief" ontwerp zal bepalen hoe steden zullen evolueren. Een voorbeeld hiervoor zijn stedelijke digital twins. </br> AIOTI & Smart Cities </br> IoT speelt een steeds voornamere rol in slimme steden. Binnen AIOTI zijn er verschillende werkgroepen. In de context van VLOCA bespreken we kort 2 werkgroepen rond IoT standaardisatie en Smart Cities. De werkgroepen worden weergegeven in [3] </br> </br> AIOTI WG03 : IoT Standaardisatie </br> Deze werkgroep heeft heel wat rapporten gepubliceerd [4] </br>Daarbij werd een High Level Architecture gedefinieerd in [5] met definitie van een Netwerk Laag, een IoT laag en een Applicatie laag, en hun interacties. De IoT laag focust op de schaalbare ontsluiting van IoT data door middel van een voorstelling van een "ding" met zijn semantische metadata. Bovendien is er aandacht aan "device management", ontdekken van devices, locatie,... Identificatie van de "dingen", applicaties en diensten, communicatie, data, locatie, protocol en gebruiker is daarbij een belangrijk element. Bevondien wordt er dieper ingegaan op het uitrollen van deze architectuur en verbanden met andere functionele modellen (van bijvoorbeeld OneM2M en RAMI 4.0). </br>Er werden ook nog papers gepubliceerd rond semantische interoperabilitiet in samenwerking met andere (standaardisatie) Organisaties en bedrijven. In [6] wordt het belang van semantische interoperabiliteit uitgelegd, en worden ook aanbevelingen gedaan voor semantische interop Standaarden door het gebruiken van ontologieen .</br> </br> AIOTI WG08 : Smart Cities </br> Deze werkgroep heeft aanbevelingen gedaan voor grote Smart City piloot projecten. Daarbij ligt de focus op de echte noden en problemen van de vraagzijde (burgers en steden) en wat de uitdagingen en technologieen zijn aan de aanbod zijde. Daarbij zijn de sleutel succes factoren schaalbaarheid en repliceerbaarheid door interoperabiliteit in de data laag, duurzaamheid vanuit economisch en sociaal perspectief en een hefboomeffect voor het locale digitale leven en digitale economie in Europese steden.</br>In 2015 werd er een rapport [7] met aanbevelingen gepubliceerd voor het opzetten van large scale (IoT) piloot projecten. </br>Een belangrijk kenmerk van IoT in stedelijke context, is de nood aan de combinatie van data uit verschillende domeinen ( Cross-Domain ) om smart city toepassingen mogelijk te maken. In 2018 werd hiervoor een rapport [8] gepubliceerd met technieken voor het repliceren van smart city toepassingen. Deze technieken zijn dan ook relevant in een Open [[::Category:Open_Smart_City_Architectuur| Smart City Architectuur]] en hier worden er een aantal opgelijst :</br> </br> definieren en delen van goede praktijken </br> oplijsten van gemeenschappelijk en veel voorkomende (Cross-Domain) use cases </br> interoperabiliteit als sleutel principe </br> een platform benadering </br> zoveel mogelijk gebruik van verticale en horizontale Standaarden </br> De aanbevelingen van dit document zijn :</br> </br> Steden moeten horizontaal denken voor hun aankoop processen wegens de groeiende nood aan cross-domain toepassingen </br> Het delen van inzichten en ervaring tussen steden zijn de sleutel tot het beter begrijpen van de kosten en baten van deze toepassingen </br> Een horizontale benadering gaat in wezen over een robuste data infrastructuur om dit toe te laten. </br> </br> </br> </br> </br> ↑ https://aioti.eu/2793-2/ </br> </br> ↑ https://aioti.eu/iot-enabled-smart-cities-and-communities-here-to-stay-and-grow/ </br> </br> ↑ https://aioti.eu/working-groups/ </br> </br> ↑ https://aioti.eu/aioti-wg03-reports-on-iot-standards/ </br> </br> ↑ https://aioti.eu/wp-content/uploads/2018/06/AIOTI-HLA-R4.0.7.1-Final.pdf </br> </br> ↑ https://aioti.eu/wp-content/uploads/2018/06/AIOTI-HLA-R4.0.7.1-Final.pdf </br> </br> ↑ https://aioti.eu/wp-content/uploads/2017/03/AIOTIWG08Report2015-Smart-Cities.pdf </br> </br> ↑ https://aioti.eu/wp-content/uploads/2018/06/AIOTI-WG08-Smart-City-Replication-Guidelines-Part-1-Cross-Domain-Use-Cases-V1.0-with-new-logo.pdf  +
• Wikipedia definieert interoperabiliteit [ … Wikipedia definieert interoperabiliteit [1] voor producten, systemen of Organisaties als ze zonder beperkingen kunnen samenwerken. Interoperabiliteit is noodzakelijk als de samenwerking van entiteiten noodzakelijk is en als de entiteiten autonoom of heterogeen zijn. Binnen een open city architectuur is interoperabiliteit een belangrijke uitdaging, aangezien het de bedoeling van een open smart city is om zoveel mogelijk heterogene entiteiten met elkaar te laten samenwerken, om de complexe (cross-domain) uitdagingen aan te kunnen. Daarom is er ook een groot verschil met "intra-operabiliteit", waar de entiteiten wel samenwerken binnen 1 "vendor locked-in" systeem (bijvoorbeeld van 1 software of platform leverancier), maar niet of heel moeilijk met entiteiten van een andere leverancier. Binnen een open city architectuur, is het de bedoeling om door open standaarden , protocollen en procedures een zo granulair mogelijke interoperabiliteit tussen entiteiten te kunnen realiseren. Het Europees Interoperabiteitskader [2] besteedt hier uitvoerig aandacht aan, en deelt interoperabiliteit op in verschillende lagen zoals hieronder weergegeven. Het Europees Interoperabiliteitskader beschrijft interoperabiliteit als volgt: "het vermogen van organisaties tot interactie met het oog op wederzijds voordelige doelstellingen, waarbij informatie en kennis tussen deze organisaties worden uitgewisseld via de bedrijfsprocessen die zij ondersteunen, door middel van de uitwisseling van gegevens tussen hun ICT-systemen" (EIF, 2017, p. 5) [2] . </br> </br> Interop EIF lagen </br> Daarbij zijn de lagen de volgende :</br> </br> achtergrond laag : "interoperability governance" </br> transversale of cross-cutting laag : "integrated public services governance" </br> technische interoperabiliteit </br> semantische interoperabiliteit </br> organisationele interoperabiliteit </br> juridische interoperabiliteit </br> </br> ↑ https://nl.wikipedia.org/wiki/Interoperabiliteit </br> </br> ↑ 2,0 2,1 https://ec.europa.eu/isa2/sites/isa/files/eif_brochure_final.pdfrochure_final.pdf  +
• Work in Progress Within the knowledge hu … Work in Progress </br> Within the knowledge hub, semantic annotations are used to categorise and organise the information. This page describes the annotations as wel as their meaning.</br>The following two main annotations will be used:</br> </br> Categories; organises the content in different groups; e.g. the ** Standaarden ** category is used to group standards- related information </br> properties; used to identify important common aspects; e.g. the **dataformaat** property is used to identify this aspect from existing projects. </br> Categories </br> Gerelateerd werk </br> [[Category:Gerelateerd werk]]</br> </br> This category is used when discussing activities related other smart city initiatives; this can be other projects (e.g. Synchronicity), or industry group standardising software components/technology (e.g. FIWARE, AOSC) </br> </br> Principes </br> [[Category:Principes]]</br> </br> This category relates to key concepts underlying smart city deployments. It contains both software components(), and architectural concepts() </br> </br> Begrippen </br> [[Category:Begrippen]]</br> </br> Used for definitions (e.g. API), key technology components (e.g. context broker)</br> </br> Standaarden </br> [[Category:[[:Category:Standaarden| Standaarden]]]]</br> </br> Used for all pages that describe a standard.</br> </br> Properties </br> dataformaat </br> used to specify a data format</br> Example [[dataformaat::json]]</br> </br> protocol </br> storage </br> domein </br> bouwsteen ? Principes </br> standaard </br> status </br> locatie </br> partners </br> naam status locatie partners naam  +
• Zweden heeft een aantal gidsen uitgebracht … Zweden heeft een aantal gidsen uitgebracht in verband met Smart Cities :</br> </br> Gids voor een slimme samenleving : https://webbutik.skr.se/sv/artiklar/guide-for-ett-for-ett-smart-samhalle.html </br> Gids voor IoT : https://webbutik.skr.se/sv/artiklar/klassa-for-iot.htmlrtiklar/klassa-for-iot.html  +
• [Storage] Het hart van een data platform … [Storage]</br> Het hart van een data platform vormt de capaciteit om (meta) data op te slaan. Data opslag moet steeds overwogen worden in kader van de behoeften, zoals lokale behoeften in het platform (vb. voor toepassingen uit het Compute segment) of voor het delen van (meta)data via de Broker of Service segmenten. Daarbij is het belangrijk om dit op schaal en fit for purpose te doen. Niet alleen performantie speelt daarbij een rol, maar ook de kost (bv cold versus hot storage). Mogelijke opslagsystemen zijn data warehouses, data lakes en data lakehouses, die fit-for-purpose moeten gekozen worden. Een belangrijke aspect is aandacht voor retentie (hoe lang moet iets bewaard blijven) en archivering (opslaan voor de archieven, dus uitgaande van het feit dat de data niet snel operationeel nodig is).</br> [Logistics]</br> Bovendien moeten er data connecties gemaakt worden tussen verschillende andere segmenten en hun componenten. Data moet kunnen stromen en ook dit moet schaalbaar kunnen gebeuren en fit-for-purpose. Zo bestaan er verschillende systemen om data boodschappen georganiseerd te laten stromen tussen data eindpunten, met ontkoppeling en buffering. Dit moet ook het ook mogelijk maken om data projecties mogelijk te maken en snel afgeleide stromen (bijvoorbeeld toevoegen van bepaalde metadatering) te creeeren.en van bepaalde metadatering) te creeeren.  +
• foaf:homepage ( foaf | Friend Of A Friend ) URL of the homepage of something, which is a general web resource. (en)  +
• foaf:knows ( foaf | Friend Of A Friend ) A person known by this person (indicating some level of reciprocated interaction between the parties). (en)  +