"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.
V
Class
VlocaSessie with pagetitle format next_available Allowed namespaces:
VlocaSessie Has version history: false
Layout
Areas : 'sub-header sidebar' 'main sidebar'
Columns : 3fr 1fr
Rows : auto 1fr
Storage templates
Base properties: Template:Base properties
Page properties: Template:VlocaSessie properties
Component templates
Sidebar template: Template:VlocaSessie sidebar
Defined parameters
Name
Property
Slot
Formfield type
Allowed values
Required
Multiple
Automatically generated template code
Info
Page properties template
Sidebar template
Open one of the tabs to view automatically generated template code. This is meant to be used when creating new templates.
If you are modifying an existing template, it might still be useful to update the parameter definitions and use parts of the generated code, but be careful not to completely overwrite existing templates. Existing templates will likely have had other modifications that are not included in the automatically generated code.
Template:VlocaSessie properties
<noinclude>
This is the '''Csp class properties''' template. It should be called in the following format:
<pre>
{{Csp class properties
}}
</pre>
</noinclude><includeonly>{{#set:
}}</includeonly>
Template:VlocaSessie sidebar <noinclude>
This is the '''Vloca default sidebar''' template. It should be called in the following format:
<pre>
{{Vloca default sidebar}}
</pre>
</noinclude><includeonly><!--
-->{{#vardefine:@allow sidebar edit |{{#ifingroup:user |{{#if:{{#urlget:veaction}}{{#urlget:action}}||yes}} }} }}<!--
--><div class="tab-content"><!--
-->{{#tag:_input||type=radio|id=sidebar-view|name=toggle-sidebar|checked=checked|class=d-none sidebar-view}}<!--
--><div class="card sidebar-view-tab">
<div class="card-header">{{#ifeq:{{#var:@allow sidebar edit}} |yes |<span style="float:right">{{#tag:label|Edit|for=sidebar-edit|class=btn btn-secondary}}</span>}}
<b class="d-block">{{#caprint:$base[Base properties][Class]}}</b>
{{#caprint:$base[Base properties][Title]}}
</div><!-- end of .card-header -->
<div class="card-body">
</div><!-- end of .card-body -->
</div><!-- end of .card
-->{{#ifeq:{{#var:@allow sidebar edit}} |yes |<!--
-->{{#tag:_input||type=radio|id=sidebar-edit|name=toggle-sidebar|class=d-none sidebar-edit}}<!--
--><div class="card sidebar-edit-tab"><!--
--><form action="addToWiki"><!--
// _edits for base properties
--><!--
// _create or _edits for page properties
// use casize to check if the slot already exists. Then _edit, else _create.
-->{{#if:{{#casize:$class}}
|
|<_create mwwrite="{{FULLPAGENAME}}" mwtemplate="Csp class properties" mwslot="ws-class-props" mwfields="" />
}}<!-- end of #if -->
<div class="card-header"><span style="float:right">{{#tag:label|Close|for=sidebar-view|class=btn btn-secondary}}</span>
<b class="d-block">{{#caprint:$base[Base properties][Class]}}</b>
{{#caprint:$base[Base properties][Title]}}
</div><!-- end of .card-header -->
<div class="card-body">
<div class="text-right">
{{#tag:label|Close|for=sidebar-view|class=btn btn-secondary}}
<input type="submit" value="Save" class="btn btn-primary" />
</div>
</div><!-- end of .card-body -->
</form>
</div><!-- end of .card -->
|}}<!-- end of #ifeq @allow sidebar edit == yes -->
</div><!-- end of .tab-content
--></includeonly>
Class
VlocaTraject with pagetitle format title Allowed namespaces:
VlocaTraject Has version history: false
Layout
Areas : 'sub-header sidebar' 'main sidebar'
Columns : 3fr 1fr
Rows : auto 1fr
Storage templates
Base properties: Template:Base properties
Page properties: Template:VlocaTraject properties
Component templates
Sidebar template: Template:VlocaTraject sidebar
Defined parameters
Name
Property
Slot
Formfield type
Allowed values
Required
Multiple
Automatically generated template code
Info
Page properties template
Sidebar template
Open one of the tabs to view automatically generated template code. This is meant to be used when creating new templates.
If you are modifying an existing template, it might still be useful to update the parameter definitions and use parts of the generated code, but be careful not to completely overwrite existing templates. Existing templates will likely have had other modifications that are not included in the automatically generated code.
Template:VlocaTraject properties
<noinclude>
This is the '''Csp class properties''' template. It should be called in the following format:
<pre>
{{Csp class properties
}}
</pre>
</noinclude><includeonly>{{#set:
}}</includeonly>
Template:VlocaTraject sidebar <noinclude>
This is the '''Vloca default sidebar''' template. It should be called in the following format:
<pre>
{{Vloca default sidebar}}
</pre>
</noinclude><includeonly><!--
-->{{#vardefine:@allow sidebar edit |{{#ifingroup:user |{{#if:{{#urlget:veaction}}{{#urlget:action}}||yes}} }} }}<!--
--><div class="tab-content"><!--
-->{{#tag:_input||type=radio|id=sidebar-view|name=toggle-sidebar|checked=checked|class=d-none sidebar-view}}<!--
--><div class="card sidebar-view-tab">
<div class="card-header">{{#ifeq:{{#var:@allow sidebar edit}} |yes |<span style="float:right">{{#tag:label|Edit|for=sidebar-edit|class=btn btn-secondary}}</span>}}
<b class="d-block">{{#caprint:$base[Base properties][Class]}}</b>
{{#caprint:$base[Base properties][Title]}}
</div><!-- end of .card-header -->
<div class="card-body">
</div><!-- end of .card-body -->
</div><!-- end of .card
-->{{#ifeq:{{#var:@allow sidebar edit}} |yes |<!--
-->{{#tag:_input||type=radio|id=sidebar-edit|name=toggle-sidebar|class=d-none sidebar-edit}}<!--
--><div class="card sidebar-edit-tab"><!--
--><form action="addToWiki"><!--
// _edits for base properties
--><!--
// _create or _edits for page properties
// use casize to check if the slot already exists. Then _edit, else _create.
-->{{#if:{{#casize:$class}}
|
|<_create mwwrite="{{FULLPAGENAME}}" mwtemplate="Csp class properties" mwslot="ws-class-props" mwfields="" />
}}<!-- end of #if -->
<div class="card-header"><span style="float:right">{{#tag:label|Close|for=sidebar-view|class=btn btn-secondary}}</span>
<b class="d-block">{{#caprint:$base[Base properties][Class]}}</b>
{{#caprint:$base[Base properties][Title]}}
</div><!-- end of .card-header -->
<div class="card-body">
<div class="text-right">
{{#tag:label|Close|for=sidebar-view|class=btn btn-secondary}}
<input type="submit" value="Save" class="btn btn-primary" />
</div>
</div><!-- end of .card-body -->
</form>
</div><!-- end of .card -->
|}}<!-- end of #ifeq @allow sidebar edit == yes -->
</div><!-- end of .tab-content
--></includeonly>
Er is geen duidelijke verdeling tussen een vocbularium en een ontologie . Ontologie wordt meer gebruikt voor complexe en formele verzameling van termen. In de stricte zin van het woord is een vocabularium een context-loze lijst van termen met geen gedefinieerde relaties. Een ontologie daarentegen impliceert wel de aanwezigheid van relaties tussen de termen, axiomas, klassen, ... +
W
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.
Opmerking: het Web of Things is nauw verbonden met het werk van W3C op het Web of Data [1] .
Web of Things Architecture [2]
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.
WoT Principes
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.
Things
Een Web Thing heeft vier architectonische aspecten:
zijn Behavior,
zijn Interaction Affordances,
zijn Security Configuration
en zijn Protocol Bindings.
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.
WoT building blocks
De Web of Things (WoT) bouwstenen maken het mogelijk om systemen te implementeren die voldoen aan de abstracte WoT-architectuur.
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.
Web of Things Description [3]
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.
[Category:Standaarden]
Referenties
↑ https://www.w3.org/2013/data/
↑ https://www.w3.org/TR/wot-architecture/
↑ https://www.w3.org/TR/wot-thing-description/
WS4water_antwerpen +
This is the WSNavMenu/Multilevel template. It should be called in the following format:
{{WSNavMenu/Multilevel
|Input=@ <menu item>
@@ <menu sub-item page> * <displayed text>
@@ <menu sub-item>
@@@ <menu subsub-item page> * <displayed text>
@@@ <menu subsub-item page> * <displayed text>
@@@ <menu subsub-item>
@@@@ <menu subsubsub-item page> * <displayed text>
}}
Example (note: spaces before the @@ are optional, not required):
{{WSNavMenu/Multilevel
|Input=@ Organisatie
@@ HR
@@ Platform
@@@ Datacenter
@@@@ Datacenter/Overzicht*Overzicht
@@@@ Datacenter/Procedures & Werkinstructies*Procedures & Werkinstructies
@@@@ Datacenter/Algemene pagina's*Algemene pagina's
@@@@ Datacenter/Technische pagina's*Technische pagina's
}}
Organisatie HR Platform Datacenter Overzicht Procedures & Werkinstructies Algemene pagina's Technische pagina's Support Recent changes +
Waarom repair data loggen? +
Om de impact te kunnen meten van repair cafés op de samenleving (bijvoorbeeld vermeden afval en milieudruk), willen we zoveel mogelijk nuttige gegevens registreren over de repair cafés: frequentie, welke toestellen worden binnengebracht, hoe oud zijn deze toestellen, wat is er precies stuk, kan het gemaakt worden, welke onderdelen moeten gemaakt worden, zijn er vervangingsonderdelen nodig, van waar komen die onderdelen, welke toestellen kunnen niet gemaakt worden en waarom niet, etc. Om al deze gegevens te kunnen verzamelen, zodat deze informatie kan gebruikt worden om bijvoorbeeld de vermeden impact te berekenen of om circulariteit (e.g. levensduurverlenging) te meten, zijn er standaard dataformaten nodig. Maar niet alleen voor de impactmeting zijn de data belangrijk. Fabrikanten gebruiken ze bijvoorbeeld voor het aanpassen en verbeteren van productontwerpen, en om de after sales afdeling bij te staan in het leveren van een goede dienst na verkoop. En meer algemeen, des te meer gegevens bijgehouden en gedeeld worden, des te beter alle stakeholders in een waardeketen kunnen samenwerken.
Volgende draaiboeken gaan over alles wat met de gegevens rond het herstel gebeuren te maken heeft:
Open Repair Data Standaard (ORDS): Welke data standaard bestaat er in het repair landschap?
Digitale Product Paspoorten (DPP): Hoe het Digital Product Paspoort gebruiken +
Doelgroep en doel
Dit hoofdstuk heeft als doel deelnemers en potentiële deelnemers aan VLOCA activiteiten wegwijs te maken in de context en activiteiten rond een thema. We nodigen graag experten uit om deel te nemen aan de co-creatie, door kennis en visie te delen in VLOCA trajecten en informatie te bundelen op deze kennishub. Experten in de materie van waste management en het beheer van data rond dit thema zijn onze doelgroep.
Op deze manier brengen we alle stakeholders samen om een gezamenlijke visie en architectuur te ontwikkelen rond use cases binnen dit thema.
Bereik ons
Team VLOCA is voor nieuwe vragen best steeds per email te bereiken op VLOCA@Vlaanderen.be . We verzorgen steeds een permanentie in ons team en dispatchen uw vraag naar de persoon die op dat moment kan werken aan uw vraag.
Inleiding
Als startpunt biedt Wikipedia ons een algemene beschrijving van de thematiek: waste management (Engels). Binnen VLOCA werken we mee aan de data aspecten van deze smart city component, vertrekkend vanuit subthema's en daaraan gerelateerde use cases.
Gelinkte pagina's op de Kennishub
VLOCA Trajecten
Geen VLOCA Trajecten gevonden
Co-creatie aanvragen
Geen co-creatie aanvragen gevonden
Initiatieven
Geen initiatieven gevonden
Draaiboeken
Geen draaiboeken gevonden
Standaarden
Geen standaarden gevonden +
Wat is een repair café en hoe kan ik er een starten? +
Concept van een repair café
Een Repair Café is een bijeenkomst die draait om repareren, georganiseerd op buurtniveau. Men kan er meegebrachte kapotte spullen repareren met hulp van vrijwilligers. Doelstellingen zijn het verkleinen van de afvalberg, het behouden van kennis over repareren en het versterken van de sociale cohesie. (bron: Wikipedia) Repair cafés worden meestal gehouden op gemeenschapslocaties, waaronder kerken, bibliotheken en campussen waar gereedschap beschikbaar is en waar eigenaren hun kapotte goederen kunnen repareren met de hulp van vrijwilligers, of waar ervaren vrijwilligers complexere reparaties uitvoeren terwijl ze worden bijgestaan door de eigenaren. (bron: SHAREPAIR)
Er zijn over de hele wereld veel reparatiegroepen. Onderstaande afbeelding geeft een indruk van de verspreiding van de 2447 reparatiegroepen die aangesloten zijn bij Repair Café International, een stichting die reparatie weer onderdeel wil maken van de lokale gemeenschap[1]. Naast dit netwerk bestaan er nog vele andere netwerken zoals het wereldwijde Restarters-netwerk[2], of dichter bij huis het Repair&Share-netwerk[3] in Vlaanderen of het Repair Together-netwerk[4] in Brussel en Wallonië.
Figuur 1 Wereldwijd netwerk van Repair Café international (bron: https://www.repaircafe.org/bezoeken/)
Iedereen kan een nieuwe reparatiegroep starten of een reparatie-evenement organiseren. Bestaande reparatiegroepen en netwerken staan bij met kennis en middelen zoals een startup kit dat je kan bestellen bij Repair Café International[5]) of via lokale overheden en organisaties (bijvoorbeeld een training van Avansa Limburg[6]).
Er zijn een aantal huisregels waar een repair café aan moet voldoen[7]. Zo bieden de vrijwilligers hun expertise vrijwillig (dus onbezoldigd) aan. De eigenaar mag een (financiële) vergoeding geven of doneren, maar steeds op vrijwillige basis. In principe is het de product eigenaar die zelf aan de slag gaat onder begeleiding van de reparatiedeskundige. Samen leren ze hoe een reparatie uit te voeren. Op deze manier kunnen noch de organisatoren van het Repair Café, noch de reparatiedeskundigen aansprakelijk worden gesteld voor enige directe of indirecte schade die zou kunnen voortvloeien uit adviezen of aanwijzingen betreffende reparaties.
Allerhande communicatie kanalen, zoals posters in een openbare ruimte, sociale media of een lokale evenementenkalender, kunnen gebruikt worden om burgers op de hoogte te brengen van het evenement. Ze worden uitgenodigd om een kapot product (afhankelijk van de focus: elektrisch apparaat, elektronica, textiel, fiets, meubels,…) naar het evenement te brengen, melden het product aan bij aankomst aan een receptietafel en beginnen vervolgens met repareren, samen met een vrijwilliger.
[1] Repair Café International. “Starten”. https://www.repaircafe.org/meedoen/starten/ bezocht 09/09/2022
[2] Avansa Limburg “Ondersteuning Repair Cafés”. https://avansa-limburg.be/projecten/ondersteuning-repair-cafes, bezocht 09/09/2022
[3] https://www.repaircafe.org/en/house-rules/
[4] Repair Café International, https://www.repaircafe.org/, bezocht 09/09/2022
[5] Restarters network: https://restarters.net/
[6] Repair&Share network: https://repairshare.be/kaart/
[7] Repair Together network: https://repairtogether.be/en/
Wat is er nodig om 24/7 dienstverlening toegankelijk te maken voor alle burgers? +
Wat is het SHAREPAIR project? +
SHAREPAIR is een project gegund onder het Interreg NW Europe programma. Het project is opgestart in februari 2020 en loopt tot mid 2023.
SHAREPAIR gaat de strijd aan tegen een van de snelst groeiende afvalstromen in de EU, die van elektrische en elektronische apparatuur met een groei van 3-5% per jaar. De algemene doelstelling is om de hoeveelheid afval te verminderen door herstellers actief in repair cafés bij te staan (doel: 6,27 ton vermeden afval) alsook de burgers woonachtig in de aangesloten steden (Leuven, Roeselare, Ottignies/Louvain-la-neuve, Apeldoorn) te ondersteunen zodat ook zij meer kiezen voor herstel (doel: 27,5 ton vermeden afval in elke aangesloten stad).
Het project wil dit doel bereiken door burgerreparatie op te schalen via bewustmaking en het gebruik van digitale tools. Deze digitale tools stimuleren en faciliteren burgerreparaties door reparatieoplossingen te verzamelen en deze gemakkelijk toegankelijk te maken voor burgers. Ze zullen burgers ook de weg wijzen naar de beste reparatieoplossingen in hun buurt[1].
Het consortium bestaat uit 17 Europese partners verspreid over Ierland, Groot-Brittannië, België, Duitsland en Nederland. Het omvat steden, universiteiten en onderzoekscentra, maatschappelijke organisaties, softwareontwikkelaars, sociale ondernemingen en consumentenorganisaties.
Stakeholder
Uitdagingen
Repairgroep
Deelnemers repair café motiveren tot het ingeven van de data is een drempel.
Repair netwerk
Een samenwerking opzetten tussen de verschillende partijen in het repair ecosysteem die snel en efficiënt is, is een hele uitdaging;
IT
Uitdaging van het op gang krijgen van de cocreatie;
Kennis bundelen via standaarden (OSLO);
Samenbrengen van gebruikers op 1 platform en gebruikers motiveen het platform te blijven gebruiken.
Lokale overheden
Momenteel is er geen mogelijkheden als stad om het beleid op te volgen. Stijgt het aantal herstellingen? Waaraan is dat te danken? Impact repair café op afvalreductie?
De Kringwinkel
Hoe laaggeschoolden en vrijwilligers intrinsiek motiveren om data in te voeren in een toepassing, terwijl de kerntaak de reparatie en het sociaal contact is?
De professionele hersteller
Match tussen soorten van producten (veel combi’s) en een databank op soort & modelnummer loopt vaak vast (bv. een wasmachine die ook droogt…). Verschillende benamingen voor combinaties van toestellen. Hoe catalogeren?
Onderzoek – data technisch
Kritische massa. Database moet aantal records bevatten. Pas dan nuttig.
Foto’s opslaan goede manier van documenteren (data verandert, foto blijft)
Onderzoek - CE
Producenten ook motiveren en aansporen bij te dragen door data te delen maar eveneens door producten anders te ontwerpen, wisselstukken goedkoop aan te bieden etc.
[1] https://www.sharepair.org/about-sharepair bezocht 09/09/2022
Wat zijn de belangrijkste noden voor jullie bestuur om 24-7 producten en documenten beschikbaar te stellen?.jpg +
Wat zijn de belangrijkste noden voor jullie bestuur om 24/7 producten en documenten beschikbaar te stellen? +
Gelinkte pagina's op de Kennishub
VLOCA Trajecten
Geen VLOCA Trajecten gevonden
Co-creatie aanvragen
Geen co-creatie aanvragen gevonden
Initiatieven
Geen initiatieven gevonden
Draaiboeken
Geen draaiboeken gevonden
Standaarden
INSPIRE-data-standaard +
zie pagina VLOCA:Data Terms & Concepts +
Presentation
Kennismaking presentatie
Voorstelling agenda en afspraken
Slides 1-3
Inleiding VLOCA trajecten (Ken Daems, ABB )
Slides 3-11
Water in de Stad (Nele D’Haese ( VITO ) en deelnemers)
Intro
Slides 12-18
Projecten
De basisinfo over deze projecten bevindt zich in de slides. Slides 19-29
B-Watersmart (Isabelle Neyskens, stad Mechelen)
Accelerating Water Smartness in Coastal Europe
Dit project draait om de inzet van een bufferbekken om de afvoer van rioolwater te bufferen, maar vanuit de droogteproblematiek wil men bekijken hoe dit water ingezet kan worden voor subirrigatie in de landbouw. Hiervoor worden verschillende sensoren ingezet.
Kwantiteit en kwaliteit
Hydrologisch meetnet provincie Antwerpen (Frie Van Bauwel, provincie Antwerpen)
Het hydrologisch meetnet van de provincie Antwerpen is gericht op een realtime opvolging van het waterpeil in de Antwerpse waterlopen. Zowel droogteproblematiek als wateroverlast kunnen gedetecteerd worden. Er wordt gewerkt met ultrasone sensoren met een periodiciteit van 15min. De overschrijding van waak- en alarmpeilen wordt gedetecteerd.
Kwantiteit
Internet of Water (Koen Triangle, IMEC )
Internet of Water Flanders
Dit project beslaat het volledige onderzoek voor het opzetten van het IoW, van sensor tot finale applicatie, van het IT-gedeelte t/m de finale operationalisering. Er wordt bekeken hoe de verkregen dat ingezet kunnen worden voor het beleid.
Kwaliteit
Q: Wordt er met andere projecten afgestemd voor de locaties van de sensoren, Dit kan omwille van allerlei redenen, zoals onderhoud, nuttig zijn.
A: Onderhoud wordt toch eerder apart bekeken, het gaat om andere expertise. [antwoord beperkt tot concreet antwoord op onderhoud, issue is breder]
Q: Heeft IoT nog nood aan use-cases?
A: Nu staan er een 40-tal locaties op de shortlist, maar input voor de long-list is steeds welkom.
Koppeling IoT peilsensordata (Willem Defloor, VMM )
Dit project kent veel paralellen met het project hydrologisch meet,et van de provincie Antwerpen. Op onbevaarbare waterlopen wordt een fijnmazig netwerk van sensoren uitgerold dat men wil testen voor laangwatervoorspellingen, maar ook hoogwater. Daarnaast wordt gewerkt aan een efficënt IoT platform.
Kwantiteit
Q: Hoeveel sensoren worden er geplaatst?
A : In de pilootfase (eerste 5 maanden) 50. Er wordt een tweetrapsstrategie toegepast en 2021 worden er nog meer bijgeplaatst. Het is fijnmazig, zowel geografisch als in tijd (periodiciteit 15min).
Monitoring van de Laak (Tine Cahy, VERA)
De laak kampt met veel illegale lozingen en de huidige detectie is te fragmentarisch; waterkwaliteitsmetingen gebeuren slechts on de 2 jaar en dan is het kalf al vergiftigd. VERA wil kort op de bal spelen, dus snel detecteren zodat snel gehandeld kan worden.
Kwaliteit, in 2de instantie ook kwantiteit
Q: Welke kwaliteitsaspecten worden gemonitord?
A: liefst zo’n breed mogelijk spectrum, maar focus in eerste instantie op zuurstofgehalte want rapporten wijzen uit dat daar het grootste probleem zit, maar graag dus ook pH en temperatuur.
Pro-active flood-detection (Koen Hilgersom, Hydroscan)
De klimaatsverandering zorgt voor meer extremen: meer wateroverlast in bepaalde seizoenen en dan weer watertekort in andere. Dit project moet ervoor zorgen dat pro-actief gehandeld kan worden door een end-to-end systeem en een algoritme voor neerslagvoorspellingen. Dit moet toelaten te komen tot wateroverlastvoorspellingen.
Kwantiteit
Opmerking: Er is hier toch scope om ook kwaliteitsmetingen mee te nemen, immers overflows kunnen zeer vervuilend zijn.
Rainbrain (Hans Vercammen, stad Roeselare)
Roeselare bevindt zich hydrografisch in een trechterpositie, aan de flessenhals van de Mandel. Er zijn zowel droogte-effecten, mee aangedreven door het hitte-eiland effect, als wateroverlast. Dit heeft ook zijn effecten op de biodiversiteit. In dit project zoekt men naar software die metingen van pluviometers kan koppelen aan niveaumeters zodat op basis van de neerslag het peil kan voorspeld worden. Zowel voor droogte- als wateroverlastproblematiek is eenzelfde architectuur nodig.
Kwantiteit
Q: Waarop doelt u als u het heeft over biodiversiteitseffecten?
A: Dat we veel preciezer kunnen bepalen of het echt nodig is om bepaalde waterlopen af te blokken of niet.
Q: Wat wordt er net door Aquafin gemeten in dit project?
A: Dat is zeer divers en afhankelijk van de lokale omstandigehden en het project.
Smart Waterland (Gino Dehullu, stad Roeselare)
In samenwerking met het lokale onderwijsnet wordt een zeer fijnmazig netwerk van pluviometers geïnstalleerd om een beter zicht te krijgen op de spreiding van de neerslag. Het is de bedoeling om dit dan weer te koppelen met Rainbrain. Het project koppelt zo sensibilisering van leerlingen en gezinnen aan de monitoring.
Kwantiteit
Q: Wordt er een eigen model van pluviometer ontwikkeld?
A: De pluviometers worden door WVI ontwikkeld en zullen 3- printbaar zijn en deel uitmaken van een educatief pakket in ontwikkeling.
Q: Wordt er een dashboard ontwikkeld?
A: Dit gebeurt door WVI.
Stiemerlab (Peter Vos, stad Genk)
Stiemerlab kadert in een breder programma rond waterproblematiek van de Stiemervallei. Door overflow van de omliggende wijken wordt de Stiemerbeek vervuild. De monitoring van de waterkwaliteit met slimme sensoren in samenwerking met de burger moet leiden tot sensibilisering en hopelijk meer infiltratie in de niet verharde oppervlakken in de wijk.
Kwaliteit
Vertellende vlotten (Lieven Symons, waterland vzw)
Waterland is een nieuwe vzw die als verbinder optreedt tussen burger en politiek. In die optiek worden groene eilanden op binnenwateren voorzien van sensoren (temperatuur, geleidbaarheid, peil, maar ook hopelijk zuurstof) waarbij de burger real-time informatie krijgt en dit op een speelse wijze, met een belevingswaarde [cf. Zwerm-gamification project van IMinds].
Kwaliteit en kwantiteit (finaliteit sterk sensibiliserend)
Werfwater (Arne Van Baelen, Werfwater)
De doelstelling van Werfwater is de verspilling van bemalingswater tegen te gaan. Hiervoor is het belangrijk debieten in real-time te kunnen volgen. Aangezien dat ook bemalingswaterkwaliteit variable is, moet dit ook gemonitord worden. Grootschalige oplossingen zijn nodig.
Kwantiteit (en kwaliteit)
Q: Is er contact met de verschillende burgerinitiatieven in Gent en Leuven die dit op de kaart gezet hebben?
A: Ja, met Gents MilieuFront en Leuven , maar ook elders.
Bijkomend was er nog sprake van een Initiatief van DIGIPOLIS Gent dat te laat ingediend werd. Die informatie zal ook op het platform gezet worden.
Reminder: graag aanmelden op kennishub
Opmerking: er zijn veel gedeelde themata en technologieën tussen de projecten
Samen naar een gedeelde architecturale visie van VLOCA mbt water (Stefan Lefever, IMEC )
Slides 30-42
Doelstelling
Doelstelling van VLOCA is om uit relecvante en actuele domeinen zoals waterbeheer (water in de stad, zonder te hard te focussen op stad, want Vlaanderen is een nevelstad), de gemeenschappelijke digitale noden te halen met andere domeinen en daar via Standaarden een antwoord op bieden. De doelstelling van VLOCA is niet om het water domein as such te digitaliseren, maar om te aligneren met Componenten en Standaarden uit andere domeinen en zo ook cross-domain digitalisering mogelijk te maken.
Welke minimale bouwstenen zijn nodig om het maximum te halen uit alle initiatieven? Hoe kunnen data uit verschillende domeinen gekoppeld worden? Wat zijn de interoperabiliteitsproblemen? Welke principes zijn nodig?
Overlopen input
Overlopen input vanuit vragenlijsten die voorafgaand aan de workshop door de deelnemers ingevuld werden.
Thematische input: verschillende verwachtingen voor datagebruik kunnen door ze te verenigen in een uniforme aanpak leiden tot een netwerk met meer potentieel dan de afzonderlijke delen.
Meerwaarde van het Smart Water Network
Data als bruikbare grondstof om sneller SWN applicaties uit te rollen.
Voorstel
Voorstel: aanpak van OpenDei voor het architectuurmodel, het 6C-model dat toegepast wordt in verschillende domeinen (gezondheidszorg, agri-food etc.). We starten top-down omdat de WAARDE vanboven zit: Customization (applicaties), Community (samenwerking), Content/Context (data wordt info, krijgt betekenis), Computing (bewerking van data om info te verkrijgen), Cyber (van ruwe data naar eerste vorm van info), Connection (sensoren en netwerk).
De focus voor de verschillende workshops volgt dezelfde structuur, workshop 4/5 is laagoverschrijdend. We kunnen via IMEC ook contact leggen met OpenDei . Er wordt niet enkel gewerkt tijdens de workshops, maar vooral ook tussen de workshops in en dit gebeurt via de kennishub.
Semantische onderbouw als leidraad (mediawiki). Architectuur en technische vertalingen op een schaal als VLOCA heeft nood aan een semantisch houvast. Wat zijn principes, hoe verschillen die van concepten, wat is een architectuur en hoe kunnen we daar zeker zijn dat we genoeg elementen verzamelen die leiden tot een eerste interpretatie ? De MediaWiki laat toe om verwijzingen te leggen naar jargon binnen de kennishub, en dus informatie dynamisch (zoals het Web) te organiseren ipv hierarchisch. Deze semantische onderbouw moet toelaten om steeds de focus te behouden bij de doelstellingen van het uittekenen van een VLOCA architectuur.
De bedoeling is om tegen eind 2021 draaiboeken te hebben binnen de VLOCA architectuur die toelaten om cross-domain digitale oplossingen uit te tekenen.
Welke principes?
Termen en concepten dienen eenduidig verklaard te worden (bv voor aanbestedingen), Standaarden worden geformuleerd en een voorzet gegeven voor welke goed zijn.
Intermezzo: voorbeeld van output voor een typische water architectuur (SWAN)
De organisatoren linken VLOCA met grotere trajecten in het buitenland (meerwaarde voor deelnemers).
Q: Ondervangt OpenDei structuur het feit dat men lokaal strenger kan optreden, een strengere invulling kan geven?
A: OpenDei is een inspiratiebron. Doorvertaling naar Vlaamse contex zal nodig zijn; we laten ons niet beperken door OpenDei ; we gaan het niet klakkeloos volgen. Dus we laten ons niet beperken moesten er door OpenDei bepaalde grenzen worden opgelegd. (cfr. OSLO waar Europese Standaarden als basis dienen voor een lokale vertaling)
Opmerking: Ik zie een zekere alignering van projecten
Q: Bestaande projecten: zijn hun datamodellen gekend? Werken die al samen? Zijn die projecten gealigneerd?
A: OSLO wordt meegepakt in VLOCA trajecten. We moeten samenbrengen wat al bestaat. Wij stimuleren dat voor datastandaardisatie de OSLO - Standaarden worden gevolgd. Het is niet de bedoeling om OSLO -trajecten binnen VLOCA te draaien, dat is ook onmogelijk. Wel om zoveel mogelijk te aligneren met wat er in OSLO gebeurt. (PS: zie de kennishub voor de links naar geplande OSLO trajecten rond water)
Q: We gaan bestaande Standaarden bij elkaar brengen, en in een standaard architectuur bij elkaar brengen, heb ik dit goed verstaan?
A: Ja.
Q: Hoe is VLOCA afgelijnd, waar begint het en waar eindigt het?
A: het concrete traject zal bepalen wat de uitkomst is, maar het minimum minimorum moet een brede verspreiding van de draaiboeken zijn, de diepte wordt bepaalde door de trajecten zelf. Het is een co-creatie traject. Wat we doen is complementair aan bestaande initiatieven (V-ICT-OR, ACPAAS etc.).
A: De prioriteiten worden in co-creatie afgebakend. We zouden in het co-creatietraject prioriteiten willen afbakenen in samenwerking met projectleiders. Wat we doen moet een doel dienen. We moeten kennis kunnen uitwisselen, in praktijk brengen, verspreiden, De scope gaan we voor een deel gezamenlijk bepalen startend vanuit de projecten.
Discussie en werkplan workshops (moderator Piet Seuntjens, VITO )
Slides 43-56
Voorstelling werkwijze, overzicht van de flow van de workshops
Gezamenlijke agenda-setting, transparant, op basis van gelijkwaardigheid
Startvraag: Wat vinden jullie van het voorgestelde proces?
Q: is het niet beter om vanuit de data te starten? Ik kan wel de dienst al benoemen, maar nog niet de applicaties. Waarschijnlijk ligt het daaraan.
A: We redeneren vanuit applicaties omdat we moeten weten welke service/dienst er moet geleverd worden, en welke waarde er dan gecreëerd wordt. Uiteraard is die onderverdeling wat artificieel. Als zou blijken dat het dataverhaal ook relevant is voor de eerste workshop, dan nemen we zeker ook datavragen mee. (bv. databroker)
Q: Kunnen we niet beter spreken van use-cases ipv applicaties?
A: OK, het gaat nog steeds om de waarde.
Q: Moeten we geen onderscheid maken tussen pro-actief en reactief (real-time)? Hemelwaterplannen, droogteplannen zijn pro-actief. Het is moeilijk om applicaties en diensten te benoemen. De kennisopbouw vind ik wel gemakkelijk te benoemen. Het is niet altijd al mogelijk om de applicatie te benoemen.
A: benoemen van use-case en daaruit volgen dan de applicaties die dat invullen.
Q: is er geen differentiatie nodig tussen de deelnemers op basis van de verschillende lagen in de architectuur? Er worden heel veel termen gebruikt die IT-gerelateerd zijn. Daardoor is het niet altijd gemakkelijk te volgen. Wat wij willen weten als waterloopbeheerders, rioolbeheerders, … is iets anders dan wat de IT-mensen willen weten. Hoe kunnen we zorgen dat de overlap mogelijk is, dat iedereen mekaar begrijpt? Hoe kunnen we een goede overgang maken? Is dit al voldoende meegenomen in het werkproces?
A: valabele opmerking, een aandachtspunt dat we zeker zullen bekijken. Eerste workshops: inderdaad meer business en operationele profielen. Wanneer we verder discussiëren over bouwplaten, referentiearchitecturen,… hebben we ook IT-profielen nodig.
Q): Hoe worden die Standaarden en de architectuur dan verder gebruikt? Hoe zien jullie het traject na VLOCA? Is er niet alleen maar meerwaarde in een proces als er daarna ook echt iets mee gedaan wordt? Kunnen die ideeën al gedeeld worden?
A: Wanneer die matuurder zijn zullen we daar met de stakeholders wel samen rond werken.
A: Er is een apart werkpakket in het project voor het governance gedeelte [moeten we aangeven of/hoe zij hierin betrokken worden?]
Opmerking: 2 bedenkingen: 1) top-down aanpak is OK, maar vertrekken vanuit data is even valabel; 2) gemengde workshops kunnen ook nieuwe waarde creëren.
Opmerking: Het tijdspad is toch moeilijk.
Q: Wat als je een workshop mist? Hoe kan je op de hoogte blijven?
A: Er wordt gedocumenteerd op de kennishub en het VLOCA-portaal. Daar zal alles worden gedocumenteerd. Wat is haalbaar? Wat is niet haalbaar? Dat bepalen we samen. We proberen om de voorgestelde momenten wel aan te houden. Wat er behandeld wordt tijdens deze momenten zal worden bepaald, enerzijds, op basis van de voortgang, en anderzijds op basis van wat haalbaar is voor de deelnemers.
Startvraag 2: Wat willen jullie concreet gerealiseerd zien op het einde van het traject? Wanneer is voor jullie VLOCA een succes?
A: Draaiboeken, raamovereenkomsten waar lokale besturen gemakkelijk van kunnen afnemen met jaarlijkse of 2-jaarlijkse update. De meeste lokale besturen hebben geen tijd om dit zelf aan te pakken, ook niet met voorbeeldclausules. Een variant op het standaardbestek van de wegenbouw.
Q: Waar zitten de gaps, welke Standaarden ontbreken nog op dit moment?
Opmerking: Een OSLO -traject duurt verschillende maanden. Informatie delen lukt wel, misschien tot overeenstemming komen, maar meer lijkt me heel ambitieus. Nu is er maar 1 workshop…
Q: Hoe zal info gedeeld worden?
Subvraag: visulalisatie/dashboards?
Opmerking: Graag terughoudendheid met beschikbaar maken van data via dashboards, want kan iedereen dit wel even juist interpreteren? Er zijn mogelijk verschillende platforms of niveaus nodig: burger, operatoren en IT-architecten.
Opmerking: opgelet, in sommige projecten gaat het net om citizen-science, dus misschien moet er met personae gewerkt worden?
Opmerking: Vlaamse overheid wil waterdashboard bouwen: nieuw platform gefocust op doelen en beleid.
Subvraag: alarmen en monitoring?
Opmerking: Dit is een belangrijk aspect.
Opmerking: Triggers zijn nodig om het onderscheid te maken tussen data en data die tot actie nopen.
Opmerking: Data uitwisselen kan, maar als dit leidt tot iets wat risico inhoudt, dan leidt dit tot een no-go zone. Voorbeeld : alle aansturingen die bijvoorbeeld vanuit een SCADA systeem getriggerd worden (bijvoorbeeld drukkleppen,…) zijn “afgesloten” en leven in een beveiligde silo, om veiligheids- of andere redenen.
Opmerking: Artificial Intelligence zal de triggers bepalen, daar moeten we op kunnen vertrouwen.
Opmerking: Gebruik maken van bestaande kanalen zoals Geopunt.
Voorstel workshop 1, 2, 3 en 4.
De inhoud van de verschillende geplande workshops wordt summier geschetst.
Verdere feedback en voorbereiding workshop 1 (Piet Seuntjens ( VITO ) en Stefan Lefever ( IMEC ))
Slides 57-67
Piet schetst het belang van de kennishub als centraal gegeven in de trajecten.
Stefan legt uit hoe er praktisch gewerkt kan worden met de kennishub (aanmaken account, content toevoegen, taggen etc.). De kennishub werkt volgens de wiki-principes.
Afsluitend woordje (Ken Daems, ABB )
Presentation
Water workshop 1 Powerpoint
Onderwerp Van De Workshop
Watersystemen volgen niet de contouren van steden, gemeenten, provincies, polders, waterbedrijven,
of een van de andere actoren uit de waterwereld. Rivieren, beken en rioleringen lopen doorheen de
bevoegdheidsverdelingen die doorheen de jaren ontstonden. Technologische vernieuwing laat toe om
een nieuwe, IoT-laag aan het watersysteem toe te voegen. Dit creëert enorme mogelijkheden voor de
optimalisatie van ons waterbeheer, zoals de vele initiatieven tijdens de kennismaking toonden. Maar dit
stelt tevens grote uitdagingen om de governance van deze IoT-laag op een duurzame en verantwoorde
manier te organiseren. En dit met een open blik op de toekomst, en de governanceuitdagingen die deze
met zich meebrengt.
De werkshop was voor beleidsmedewerkers en andere professionals met een
strategisch profiel en het doel was om enigszins zicht te krijgen op de principes die leidend zouden
kunnen worden voor de governance van IoT-systemen in de watersector. Deze leidende principes
bepalen immers de randvoorwaarden waaronder technische architecturen en infrastructuur worden
gerealiseerd.
Waarden op basis waarvan het creatiemodel wordt gebruikt.
Wederkerigheid van data delen, quid pro quo, return van de data na toevoegen van waarde als wederdienst voor verkrijgen van data.
Opgelet voor discriminatie van stakeholders (de grote vs de kleintjes): Is er een level-playing field? Uiteenlopende gezichtspunten over vermarktbaarheid van data door derden (overheid vs. bedrijf).
Standaard afspraken rond data delen (cfr. one size fits all afspraken i.p.v. huidige custom afspraken). Wordt er gestreefd naar eenzelfde set voorwaarden waaronder bepaalde datasets worden ter beschikking gesteld? (Nu: ad-hoc afspraken per overeenkomst.)
Licenties en hoe die werken (data die gefinancierd worden met publieke middelen moeten gedeeld worden, maar op een democratische manier, waarbij kosten en baten gedeeld zijn. Als bedrijf wil ik ook de mogelijkheid hebben om de licentie van data te hebben en deze aan derden te geven, maar ik wil ook de mogelijkheid hebben om deze licentie te revoken).
Effectiviteitsprincipes (Erik Laes, VITO )
Effectiviteitsprincipes of leidende principes zijn principes die individuen, organisaties of de samenleving in haar geheel richting geven in het omgaan met innovaties in een snel veranderende omgeving.
Effectiviteitsprincipes onderscheiden zich van ethische principes. Ethische of morele principes sturen ons handelen op basis van waarden die we intrinsiek waardevol vinden (los van het feit of we het realiseren van die waarde in een concrete situatie al dan niet haalbaar achten).
Effectiviteitsprincipes kunnen weliswaar gebaseerd zijn op ethische principes, maar ze zijn evenzeer gebaseerd op overwegingen omtrent de meeste geschikte manier om een bepaalde waarde te realiseren, gebaseerd op kennis, ervaring, of overleg.
Goede effectiviteitsprincipes zijn richtinggevend, bruikbaar, inspirerend, ontwikkelingsgericht, toetsbaar
Transparantie
Transparantie betekent dat VLOCA zoveel mogelijk informatie wil vrijgeven over de
data, de processen, de standaarden en de acties die genomen worden binnen het smart city initiatief. Kernconcepten hierbij zijn:
Open data ‘by default’ (d.w.z. data die niet gevoelig van aard zijn worden in principe opengesteld)
Maximaal stimuleren van hergebruik van data (commercieel en niet-commercieel)
Data worden gepubliceerd volgens open en machine-leesbare standaarden
Duurzaamheid in het onderhouden van datasets
Samenwerken over meerdere bestuurslagen
Open en transparante communicatie in een leesbare taal over het initiatief
Respect
Dit betekent dat VLOCA respect voor de burger centraal stelt, door in te zetten op bescherming en empowerment. Kernconcepten hierbij zijn:
Autonome keuzes over delen van data mogelijk maken
Actiemogelijkheden van burgers op basis van gedeelde inzichten vergroten
Bescherming van privacy garanderen
Versterken van digitale competenties
Bijzondere aandacht voor kwetsbare groepen
Actief zoeken naar realiseren van maatschappelijke meerwaarde
Verantwoordelijkheid
Verantwoordelijkheid betekent dat de nodige processen, standaarden en interacties
voorzien worden om vertrouwen te creëren bij de gebruikers van de smart city
diensten, door o.a. een effectief toezicht op de projectuitvoering te organiseren. Kernconcepten hierbij zijn:
Kwaliteitscontrole van data
Alleen die data verzamelen die voor de dienstverlening nodig zijn
Cybersecurity
Samenwerking met partners die vertrouwd worden door burgers
Peer review door onafhankelijke experts
Data niet zonder toestemming delen met derden
Activering
VLOCA wil innovatie en ondernemerschap door burgerinitiatieven, publieke overheden en commerciële partijen stimuleren. Kernconcepten hierbij zijn:
Vermijden van vendor lock-in
Interoperabiliteit
Design met het oog op innovatie
Actief de dialoog aangaan met mogelijke hergebruikers van data(platformen)
Democratie
VLOCA voert democratische waarden hoog in het vaandel. Kernconcepten hierbij zijn:
Eigenaarschap van data van burgers ligt bij de burgers zelf
Burgerparticipatie
Democratisch toezicht
Vermijden van machtsconcentraties
Faire verdeling van de uitkomsten van het initiatief
Breakouts (Nele D’Haese, VITO )
Open data leiden niet automatisch tot efficiënte en effectieve
IoT-systemen? Het creëren van een context waarin de transfer van data in alle vertrouwen kan doorgaan is belangrijk. Spelregels afspreken die het kader verduidelijken waarbinnen data worden gebruikt, is daarom belangrijk. Deze regels moeten eerst worden bepaald:
Principes gevolgd bij de ontwikkeling van de VLOCA:
Ontwerp voor innovatie
Streven naar maatschappelijke meerwaarde
Wat zijn de behoeften en wensen van de gebruikers van een IoT-systeem?
Wat zijn de behoeften vanuit het oogpunt van innovatie?
Duurzaam (Regen) Waterbeheer in een stedelijke context wateroverlast en droogte bestrijedn
Stap 1
De eerste stap is het bepalen van de acteur die u vertegenwoordigt. Vertegenwoordig je een provincie? Een stad of gemeente? Een bedrijf? Enz.
Stap 2
Durf de toekomst in te kijken! Beantwoord de vraag:
Wat zouden je informatienoden binnen 5 jaar, binnen 10 jaar, … kunnen zijn?
Stap 3
Probeer al eens in te schatten wat de gemakkelijkste manier zou zijn om deze informatie te krijgen. Een app op je telefoon? Een dashboard? Een gewone website?
Stap 4
Van welke data ben je nu al de eigenaar?
Over welke data kan je nu al beslissen of je ze al dan niet deelt met anderen?
Stap 5
Als je antwoord hier niet hetzelfde is voor alle data die je in Stap 4 opsomde, kan je
dan duidelijk differentiëren naargelang het type data?
Onder welke condities wil je data delen? Wat betekent dit op het vlak van eigenaarschap, identificatie van de 'vragende partij', authorisatie van derden om data door te geven.
Stap 6
welke data heb ik nodig?
Als je kijkt naar de informatiebehoefte die je eerste beschreef, en de data die je al hebt (of waar je al toegang toe hebt), welke data denk je dan nog nodig te hebben?
Stap 7
Waneer zijn deze data bruikbaar voor jou? Welke eisen stel je op het vlak van kwalitijtscontrole, broncontrol, etc.
Stap 8
Ga naar het prioriteiten bord, en geef aan wat voor jou prioriteit moet krijgen. We kunnen vanuit VLOCA niet alles tegelijkertijd uitwerken. Wat zou er volgens jou voorrang moeten krijgen?
Plenaire terugkoppeling (Nele D’Haese, VITO )
Terugkoppeling uit breakout sessie 1 (Maarten van Loo)
Terugkoppeling uit breakout sessie 2 (Koen Triangle)
Terugkoppeling uit breakout sessie 3 (Astrid Philippron)
Terugkoppeling uit breakout sessie 4 (Erik Laes)
Vooruitblik naar volgende workshop (Mathias Van Compernolle, IMEC )
De inhoud van de verschillende geplande workshop wordt summier geschetst.
Presentation
Water workshop 2 Powerpoint
Onderwerp Van De Workshop
In deze workshop werd dieper ingegaan op de databeschikbaarheid. Door te werken naar standaarden
en/of principes kan een vlottere uitwisseling van data mogelijk gemaakt worden. De workshop draaide
volledig rond deze standaarden en principes.
Welke bestaan er?
Welke zijn er te verkiezen waar en wanneer en voor welk type data?
Hoe worden data best bijgehouden en met welke systemen best uitgewisseld?
Of bekeken vanuit de Open Dei referentiearchitectuur ging deze workshop over de
interfaces van Community (delen en samenwerken), Content/Context (datastandaarden) en Computing
(opslag en gebruik).
Tegelijkertijd werden ook twee andere gerelateerde initiatieven nader toegelicht bij het begin van de
workshop:
OSLO en meerbepaald het OSLO traject AIR & WATER
Data broker van AIV.
Introductie OSLO (Kevin Haleydt)
Het belang van semantische interoperabiliteit
In het kader van dienstverlening dienen overheden van verschillende niveau (lokaal, regionaal, federaal, Europees) met elkaar samen te werken
Dit gaat vaak gepaard met allerhande gegevensuitwisselingen van informatie uit verschillende:
Systemen
Administraties
Technische formaten…
Nood aan gemeenschappelijk semantische verstandhouding
Open Standaarden voor Linkende Organisaties
OSLO = Open Standaarden voor Linkende Organisaties
Robuuste en gedocumenteerde methodologie
Co-creatie als vertrekpunt voor gedragenheid
Online publicatie van de semantische (maar ook technische) standaarden in het Standaardenregister
Eindproduct van een OSLO traject
Semantisch
Applicatieprofiel
Vocabularium
Implementaties
LBLOD
AWV
CRAB
Besluitvorming
Vlaamse Codex
Raakvlakken OSLO & VLOCA Water in de stad
Betrokkenheid OSLO in VLOCA traject vanwege synergie, maar ook teneinde dubbel werk te voorkomen
Raakvlakken met reeds bestaande OSLO trajecten:
OSLO Openbaar Domein
Waterdeel
Watervoorkomen
OSLO Air & Water (focus op observaties & qualiteit)
Agentschap Wegen & Verkeer Object Type Library (OTL), namelijk deelimplementaties:
Rioleringen
Waterlopen (to be)
Dijken (to be)
Constructie-elementen (to be)
Kortom, duidelijke synergie tussen OSLO & VLOCA
Data Broker AIV (Annelies De Craene, Ziggy Vanlishout)
Sensor Data Platform
Onze Probleem is: Hoe maken we van real time sensordata een belangrijke hefboom voor duurzame groei van de Vlaamse data-economie?
huidige platformen zijn niet altijd geschikt om grote volumes sensordata aan te bieden op een
kostenefficiënte manier
smart city toepassingen zijn vandaag nog te veel maatwerk en onvoldoende schaalbaar
sensordata ontstaan in silo’s en bieden op zichzelf onvoldoende meerwaarde voor nieuwe
business modellen, niet gestandaardiseerd
een dreigende vendor lock-in op sensordata en geconsolideerde smart city markt vormt een
sterke rem op de innovatie
Sensordata zijn een groeimarkt voor de data-economie van morgen.
De effect die we beogen:
Doelstellingen
Herbruikbare open source componenten aanbieden aan de markt die kostenefficiënte publicatie van grote volumes sensordata in real time toelaat - interoperabiliteit
Inzetten op open standaarden zodat sensor data sensor-agnostisch wordt en ‘loskomt’ van de leverancier vd sensor en vlot gerelateerd kan worden aan slow moving data (vb. basisregisters)
Ecosysteemvan ‘samenwerkende’ sensor dataplatformen tot stand brengen
Business voordelen
Innovatiesnelheid en time to market van Vlaamse bedrijven gevoelig verhogen. Dit is een voorwaarde voor de veerkracht van onze Vlaamse bedrijven
Realtime en gepersonaliseerde data zijn een vereiste voor digitale transformatie geworden
Self Service by design en betaalbaar te gebruiken door de gehele markt
BREAK-OUTS
De deelnemers werden verdeeld over 3 break-outs. Elke break-out kreeg een aanzet tot beslissingsboom
voorgeschoteld op een MIRO-board als een eerste probeersel van een stappenplan om te komen tot de
beste oplossing om data beschikbaar te maken. Deze beslissingsboom werd overlopen aan de hand van
een aantal vragen over de gewenste datastandaarden, eventuele voorkeuren van dataopslagtypes en
pub/sub type. Om ergens te starten werden op basis van het ingediende huiswerk van de deelnemers
een genudgde classificatie gemaakt tussen 4 types data om de discussie te stimuleren:
sensor data
GIS data
modelresultaten
staalname data.
Datatypes
Het is duidelijk dat nog meer types data gezien worden door de deelnemers en dit afhankelijk van hun
uitgangspunt. De voorgestelde opsplitsing is een goed begin, maar niet altijd even relevant. Tevens ging het over semantiek. Een opdeling kan nuttig zijn, maar mag ons niet vastzetten. In vele gevallen zijn de
issues dezelfde voor de verschillende types. Het belangrijkste bijkomende onderscheid dat aangehaald werd is real-time versus niet-real-time of historische data.
Op die basis zouden bv. al sensordata onderscheiden kunnen worden van de andere 3 voorgestelde types. Ook alle eerder contextdata zijn niet-real-time. Een andere onderscheidingsfactor zou dan contextdata of back-end data van overheden versus andere, door data-bedrijven en sensoren geleverde data (ook wel ‘industriële data’ genoemd) kunnen zijn. En wat met data-enrichment ?
Ontologische opdelingen zoals bij WaterML zijn ook mogelijk. Voor OSLO zijn de volgende 3 parameters
primordiaal: de plaats (locatie, context,...)
de observatie data
de context van het device.
Die 3 moeten samen blijven. Dit relateert ook aan het belang van unieke Ids.
Datastandaarden
Algemeen is er een vraag naar standaardisatie; de standaard zelf doet er op zich niet toe, want
theoretisch kan je mappen tussen de verschillende datastandaarden, maar dat heeft dan natuurlijk zijn
economische plaatje. De realiteit nu is dat er vanalles en nog wat gemaakt wordt en dat bovendien
de leveranciers zelf nog een transformatie moeten doorgaan en daadwerkelijk de standaard moeten
leveren.
Daar staat tegenover dat flexibiliteit nodig is, want standaarden evolueren vandaag trager dan
technologische evoluties in sensoren en data-opslag. Tussen beide moet een evenwicht zijn en backward compatibility is daarin zeer belangrijk.
Eigen data-opslag
Eigen data-opslag is bijvoorbeeld niet interessant voor satellietdata, waar het verplaatsen van de
gigantische hoeveelheid data niet aan te raden is. Bovendien moet eigen data-opslag een duidelijk doel
hebben zoals het trainen van modellen, archivering, calibratie etc.
De IT infra moet flexibel genoeg zijn om de uitwisselbaarheid en opslag te ontkoppelen (cf. REST API ).
Wat men intern gebruikt, kan al sterk bepaald zijn door historische keuzes en de bestaande use case(s):
uitwisseling, monitoring, presentatie, exploratie, onderzoek etc. Sensor data is ook meestal niet bedoeld
voor 1 use case. Idealiter kan een database om met verschillende data-types. Hoe kan je flexibel omgaan
met multi-gebruik met andere noden, bijvoorbeeld cross-domain. Smart data wordt belangrijk!
Databases waarbij time-series verwerkt worden verschillen van databases waarbij dit niet nodig is.
Zeker indien deze data snel achter elkaar (~seconde) binnenstromen.
Zij die nog keuzes moeten maken, weten dan toch graag wat een goede keuze is voor data-opslag met
een blik op de toekomst.
Quality control
De kwaliteit van sensordata zijn een heikel punt. Hoe kan die nagegaan worden? Speelt dit enkel maar bij sensordata of is dit even relevant -maar mogelijk minder heikel- voor de andere datatypes?
Kan kwaliteitscontrole en validatie ook gestandaardiseerd worden en uitwisselbaar worden (bv.
scripts)?
Data-ontsluiting (pub/sub, API)
Pub/sub system: hoewel sommigen al aangeven de AIV data-broker te willen gebruiken, dient
genuanceerd te worden dat het nog een theoretisch concept is. Wat is beter? : self-hosted (Edge) versus
Cloud. FIWARE kan in beide gevallen gebruikt worden, want bestaat uit standaarcomponenten.
Pre-processing scripts staan best dichtbij de edge. Als de sensor/edge smart genoeg is kan daar al
voorverwerking gebeuren. Daar staat tegenover dat bepaalde klanten graag raw data hebben en andere
reeds verwerkte. Kunnen beide opties in bepaalde gevallen open blijven?
Wat met message brokers/buffers (cf. Kafka)? In functie van de concrete toepassing, kan het nodig zijn
dat informatie gebufferd wordt, omdat het verwerken ervan trager is dan de snelheid waarmee data
binnen stroomt.
API : Er moet naar een interoperabel systeem van API gegaan worden (cf. OSLO verhaal). Standaardisatie
is hierin belangrijk en een directe vraag aan OSLO. REST-API aub.
Versiebeheer is ook een belangrijk aandachtspunt.