"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.
S
Een data platform kan ook toelaten om bepaalde algoritmes op de data te faciliteren. Meer en meer heeft ruwe data te weinig business waarde, en is het data fusion of het toepassen van algoritmes op de data die de waarde toevoegen. Video stromen op ANPR camera's bijvoorbeeld hebben weinig waarde, het is het algoritme die de nummerplaten detecteert die waarde toevoegt. We zien ook meer en meer dat 1 data stroom tot meerdere afgeleide datastromen kan leiden (zoals die video stroom die nummerplaten kan detecteren, maar ook bijvoorbeeld calamiteiten of bewakingsdoeleinden kan hebben). Al die bewerkingen op de data hebben op hun beurt nood aan transformaties, opslag, ... en dus vormen die een belangrijk deel van technische capaciteiten die een data platform kan aanbieden.
Een aantal voorbeelden :
interoperabele en/of portabele modellen die kunnen ingezet worden voor simulatiedoeleinden
artificiele intelligentie algoritmes (bijvoorbeeld machine learning met training en test datasets, en inference functions)
streaming analysis, bijvoorbeeld kalibreren van sensoren op basis van andere data en hun historiek
data science
Business Intelligence & reporting +
IAM staat voor Identity and Access Management. Een data platform moet in staat zijn om de identiteit van zijn gebruikers te verifieren en op basis van die identiteit toegang te geven tot bepaalde data of data verwerking. IAM is een orthogonale capaciteit en kan bijvoorbeeld zowel toegepast worden op de visibiliteit binnen een catalogos in het Broker segment, als op toegang tot een data stroom in het service segment. +
Dit segment bevat technische capaciteiten om data te "projecteren", d.w.z data te verwerken, transformeren, verrijken, pseudonimiseren, aggregeren,... Een data platform krijgt via het Data Capture segment data van verschillende bronnen (en dus veschillende formaten en betekenis) binnen die meestal niet direct fit-for-purpose is voor business afnemers. Het is dan ook een essentieel deel van een platform om data verwerking en transformatie te faciliteren op een gestructureerde en schaalbare manier. Dit kan gaan over het structuur aanbrengen aan ongestructureerde data, data te transformeren tot een geunificeerd formaat, event data te verwerken, ... ETL (Extract Transform Load) technieken horen bijvoorbeeld thuis in dit segment. De schaalbare streaming van het Storage to Scale segment kan zo ook verbonden worden met data transformaties om bijvoorbeeld schaalbaar toch big data transformaties (bijvoorbeeld in data lakehouses) te kunnen realiseren voor business applicaties. +
Een data platform moet data aanbieden aan zijn gebruikers. Data moet gepubliceerd kunnen worden met verschillende protocols en in verschillende formaten, afhankelijk van de vereisten van de toepassingen. Dit sgement bevat technische capaciteiten om dit mogelijk te maken. Idealiter worden hier standaard APIs aangeboden (voorbeeld : Linked Data Event Streams, Fiware APIs, OGC API's, ...), met open formaten voor de data (bv Parquet formaat voor big data, maar dit kunnen evengoed JSON bestanden zijn). Het service segment kan data ook aanbieden via schaalbare infrastructuur, zoals Kafka of MQTT brokers of HTTP services. Het identificeren van de noden van de gebruikers (bijvoorbeeld rond het bevragen van de data en welke indices zoals tijd of plaats) is daarbij heel belangrijk om een schaalbare en ge-unificeerde service aan te bieden.
Deze service laag is heel belangrijk binnen het virtueel smart data platform, ook wel data space genoemd. De Vlaamse Smart Data Space biedt componenten aan om data schaalbaar en interoperable te delen en bevragen. +
[Storage]
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).
[Logistics]
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. +
De ontologie van het Semantisch Sensor Netwerk (SSN) is een ontologie voor het beschrijven van sensoren en hun waarnemingen, de betrokken procedures, de bestudeerde interessante kenmerken, de gebruikte monsters en de geobserveerde eigenschappen, alsmede de actuatoren. SSN volgt een horizontale en verticale modulariseringsarchitectuur door het opnemen van een lichtgewicht maar op zichzelf staande kernontologie die SOSA (Sensor, Observation, Sample en Actuator) wordt genoemd voor zijn elementaire klassen en eigenschappen. Met hun verschillende reikwijdte en verschillende graden van axiomatisering zijn SSN [1] en SOSA [2] in staat om een breed scala aan toepassingen en use cases te ondersteunen, waaronder satellietbeelden, grootschalige wetenschappelijke monitoring, industriële en huishoudelijke infrastructuren, sociale sensing, burgerkunde, observatiegedreven ontologietechniek, en het Web of Things.
The following figure provides an overview of the core classes and properties that are secifically related to modeling Actuations. SOSA axioms are shown in green, while SSN-only axioms are shown in blue.
[[Open Geospatial Consortium (OGC) | Overzicht van OGC Standaarden ›]]
Referenties
↑ http://www.w3.org/ns/ssn/
↑ http://www.w3.org/ns/sosa/ +
Work in Progress
Within the knowledge hub, semantic annotations are used to categorise and organise the information. This page describes the annotations as wel as their meaning.
The following two main annotations will be used:
Categories; organises the content in different groups; e.g. the ** Standaarden ** category is used to group standards- related information
properties; used to identify important common aspects; e.g. the **dataformaat** property is used to identify this aspect from existing projects.
Categories
Gerelateerd werk
[[Category:Gerelateerd werk]]
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)
Principes
[[Category:Principes]]
This category relates to key concepts underlying smart city deployments. It contains both software components(), and architectural concepts()
Begrippen
[[Category:Begrippen]]
Used for definitions (e.g. API), key technology components (e.g. context broker)
Standaarden
[[Category:[[:Category:Standaarden| Standaarden]]]]
Used for all pages that describe a standard.
Properties
dataformaat
used to specify a data format
Example [[dataformaat::json]]
protocol
storage
domein
bouwsteen ? Principes
standaard
status
locatie
partners
naam +
Dit is een primer voor het toevoegen van semantische mediakwiki markups aan wiki artikels.
De officiele handleiding voor het werken met Semantic MediaWiki is hier [1] te vinden.
Doel
WIKIs zijn heel geschikt om met een grote groep informatie te creeeren en te delen. Dit sluit dus zeer goed aan bij het doel van VLOCA, om co-creatie mogelijk te maken. Maar WIKIs zijn wel minder geschikt om data op te vragen of te aggregeren. Een voorbeeld zou kunnen zijn : "welke VLOCA componenten dragen bij tot het realiseren van semantische interoperabiliteit"?
Het doel van het gebruiken van de Semantische MediaWiki features is om gebruikers (editors) toe te laten om de structuur en de organisatie van de kennis in de wiki te verbeteren. Gezien VLOCA deze WIKI als kennishub wil aanbieden, is dit een belangrijke manier om de kennis beter doorzoekbaar te maken en te delen, zowel binnen de WIKI door gebruikers (lezers) zelf als voor externe computerprogramma's. Bij de bovenstaande vraag, zouden de componenten die bijdragen tot semantische interoperabiliteit kunnen voorzien worden van metadata die linken met de definitiepagina van semantische interoperabiliteit, en zo kan daarop heel efficient data geaggregeerd worden.
Hoe ?
Dit wordt gedaan door het toevoegen van eenvoudige, machine-leesbare meta-informatie (zogenaamde "markup") aan wiki artikels. Wiki artikels zijn alleenstaande pagina's die een bepaald subject (of entiteit) beschrijven. De pagina's zijn de ondeelbare basis van een WIKI, zoals bestanden de basis zijn van een bestandensysteem. Deze markup kan op verschillende manieren gebeuren. Dit illustreren we hieronder met een aantal voorbeelden uit de huidige inhoud van de kennishub. Meer informatie is terug te vinden onder [2] .
Categorie
Verschillende WIKIpagina's kunnen gegroepeerd (geklasseerd) worden onder 1 categorie. Huidige categorieen zijn bijvoorbeeld Architectuurcomponenten em Organisaties . Deze categorie verwijst dan naar alle pagina's die ge-annoteerd zijn om tot deze categorie te behoren. Voor de categorie "Organisaties" bijvoorbeeld zijn alle objecten die een organisatie bevatten getagged om te verwijzen naar deze categorie. Deze annotatie gebeurt door het toevoegen van indicaties zoals " Organisaties " aan de pagina die tot deze categorie behoort, zoals hieronder aangegeven voor de pagina Gaia-X :
Categoriepagina's aggregeren dus alle andere pagina's die tot deze categorie behoren. De hoofdcategorien van deze kennishub zijn terug te vinden in de linker navigatiebalk en worden voorgesteld in het schema van de relaties tussen categorieen dat hier wordt herhaald :
Verwijzingen naar paginas
Verwijzingen naar pagina's vanuit een andere pagina zijn tamelijk eenvoudig.
verwijzing naar een pagina behorende tot een categorie, voorbeeld " Gaia-X ". Het deel na "|" is de beschrijving zoals deze in de tekst moet verschijnen, het deel ervoor wijst naar de categorie en de pagina in de categorie.
deze verwijzing kan ook rechstreeks gebeuren naar een pagina, voorbeeld " van de relaties tussen categorieen ". Het deel voor de "|" is de naam van de pagina, het deel erna is de beschrijvende tekst op de verwijzende pagina.
Eigenschappen van een pagina
Zoals een categorie-annotatie de pagina klasseert, kan elke link of elk stuk tekst op een pagina ook ge-annoteerd worden met een eigenschap van het object waarover de pagina gaat. Bijvoorbeeld als een pagina de stad Berlijn beschrijft, kan een stuk tekst op deze pagina aangeven dat Berlijn de hoofdstad is van Duitsland. Maar dit blijft een stuk tekst en er kan dus enkel tekstueel opgezocht worden. Nu is het mogelijk om een eigenschap te definieren "is hoofdstad van" als een aparte entiteit op de WIKI. Deze eigenschap kan dan toegevoegd worden aan de tekst door een annotatie. Op die manier kan een gebruiker die bijvoorbeeld alle hoofdsteden wil kennen van de wereld, een zoektocht doen op de "is hoofdstad van" eigenschap en zo alle landen krijgen waar in de WIKI naar verwezen wordt via deze relatie. Dit is veel krachtiger dan te gaan zoeken op de tekst "hoofdstad" in de volledige WIKI en uit die zoekresultaten te gaan terugvinden wat nu werkelijk verwijzingen zijn die we nodig hebben. Deze eigenschappen kunnen toegepast worden op elke pagina, en dus ook op een categoriepagina. Dit is de manier waarop we de relaties tussen de categorieen uit de bovenstaande figuur hebben gemodelleerd. De categorie "componenten" bijvoorbeeld heeft een "implementeert standaarden" relatie met de categorie "standaarden". Daarvoor werden 2 zaken toegevoegd :
De eigenschap "implementeert standaarden"
Een verwijzing om aan te geven dat dit een eigenschap is van de categorie "componenten"
Door deze eigenschappen toe te voegen, krijgen deze ook een betekenis en kunnen de verschillende pagina's semantisch met mekaar gelinkt worden via relaties. Dit kan dan ook machine-leesbaar (RDF) ge-exporteerd worden en gebruikt worden door machines om bijvoorbeeld navigeerbare grafes te maken van de inhoud van de kennishub, zoals hier [3] en hieronder ge-snaphsot :
Een ander voorbeeld van annotatie van eigenschappen van een pagina met andere entiteiten is bijvoorbeeld het toevoegen van een organisatie als werkzaam binnen een bepaald smart city domein. Als voorbeeld nemen we de VMM, die werkzaam is binnen Smart Environment.
we voegen een eigenschap toe aan de tekst van de VMM organisatie :
Hier geven we aan dat er een relatie bestaat tussen de VMM en het Smart City Domein "smart environment"
Die relatie "Domein" is ook een Eigenschap pagina :
Dit is gelijkaardig aan een categoriepagina en hier worden alle pagina's opgelijst die voldoen aan deze eigenschap. Het is ook mogelijk om eigenschappen een bepaald type te geven. In dit geval MOET de eigenschap verwijzen naar een van de gedefinieerde Smart City Domeinen zoals opgelijst in de eigenschaps pagina. Het gevolg is dat de eigenschap "behoort tot een domein" op die manier een eigen leven krijgt, en het bijvoorbeeld gemakkelijk is om te zoeken op alle pagina's die zichzelf linken met een bepaald domein. Als we dus zoeken op alle pagina's die behoren tot het domein "Smart Environment" is dat eenvoudig via een zoekpagina op eigenschap zoals hieronder weergegeven, waar de VMM duidelijk mee komt in het antwoord :
Deze semantische zoekopdrachten kunnen ook via de pagina Semantic Search op een heel gemakkelijk aanpasbare manier worden opgestart. Meer info hierover is te vinden op [4] .
Extra mogelijkheden
inline semantische zoekopdrachten
Het is mogelijk om zoekopdrachten zoals hierboven beschreven te verwerken in pagina's. Meer hierover is te vinden op [5] . Dit is een zeer krachtig instrument om pagina's dynamisch te maken, en continu up-to-date te houden met de aanpassingen aan de WIKI. Dat is een interessante feature om in draaiboeken of wizards te gebruiken. Een voorbeeld zou kunnen zijn om in een wizard een lijst van eigenschappen te tonen waar een watersensor specifiek moet aan voldoen, gekaderd aan bijvoorbeeld technische interoperabiliteit. Dan volstaat het om algemene systeemeigenschappen te taggen met bijvoorbeeld de eigenschap "is specifiek voor water" en de eigenschap "realiseert technische interoperabiliteit" en de pagina over een smart water sensor blijft altijd up-to-date. Dit soort dynamiek is in een puur tekstuele WIKI niet mogelijk.
exporteren van de pagina's en hun verbanden
Het is mogelijk om een export te doen van de pagina's en hun verbanden (via de eigenschappen) naar RDF, een welgekend formaat vanuit het semantisch web, met een veelheid aan tools om dit te lezen en interpreteren. Dit maakt het automatisch genereren van grafes of subgrafes (na queries) perfect mogelijk via externe programma's. Meer informatie is hier te vinden [6] . Op die manier kan WIKI informatie en verbanden ook heel gemakkelijk door externe programma's gebruikt worden. Externe programma's kunnen bijvoorbeeld generatoren voor aanbestedingen zijn.
importeren van informatie en hun verbanden
Ook dit is mogelijk, en externe informatie kan ge-importeerd worden op de WIKI. Dit kan voor RDF, CSV, XML, maar ook Linked Data gebruik makende van bijvoorbeeld SPARQL queries.
bevragen van de WIKI met SPARQL
Naast de specifieke MediaWiki querytaal, kan de RDF data ook in een SPARQL endpoint worden aangeboden en op die manier ook met de tools van het semantisch web worden opgevraagd.
Uitdagingen
De kracht van de Semantische MediaWiki voor automatisatie is hierboven duidelijk aangetoond. Een belangrijke uitdaging is natuurlijk het opstellen van een algemeen informatiemodel voor de inhoud van de WIKI en het onderhouden van de annotaties in alignering met dit model. Er is dus meer werk aan de invoerzijde om automatisatie aan de uitvoerzijde mogelijk te maken. Tot slot geven we nog volgende link [7] naar overzicht referentie cheat sheets voor het gebruik van de MediaWiki en de semantische aspecten daarin.
↑ https://www.semantic-mediawiki.org/wiki/Help:User_manual
↑ https://www.semantic-mediawiki.org/wiki/Help:Editing
↑ https://vlocavis.z6.web.core.windows.net
↑ https://www.semantic-mediawiki.org/wiki/Help:Semantic_search
↑ https://www.semantic-mediawiki.org/wiki/Help:Inline_queries
↑ https://www.semantic-mediawiki.org/wiki/Help:Semantic_Web
↑ https://www.semantic-mediawiki.org/wiki/Semantic_MediaWiki_reference
Semantische interoperabiliteit focust op het beschrijven van de betekenis van een interactie tussen 2 interoperabele systemen of componenten . Als voorbeeld kan de specificatie van de interoperabiliteit van een protocol tussen 2 IoT toestellen die geconnecteerd zijn door een netwekr het volgende bevatten :
een semantische (betekenis) beschrijving van de mogelijkheden van de toestellen (bv. meten van temperatuur)
een semantische beschrijving van de protocols (bv. WIFI)
een semantische beschrijving van de protocol data eenheden (zoals graden Celsius)
Verder geeft WikiPedia ook nog deze beschrijving :
Hierbij ligt de nadruk op betekenis van de uitgewisselde gegevens; op het accuraat bepalen van de betekenis zodat informatie ontstaat die zinvol is voor de eindgebruikers van beide systemen. Moeilijkheden hierin kunnen bijvoorbeeld optreden wanneer verschillende termen worden gebruikt voor gelijksoortige of identieke concepten, zoals "maker", "auteur", "samensteller", "componist" (vooral wanneer deze begrippen elkaar binnen sommige contexten semantisch overlappen en in andere contexten niet), of andersom: wanneer identieke termen worden gebruikt, waarvan de betekenis in verschillende contexten verschilt. Naast deze terminologische kwesties kan ook onduidelijkheid aan de orde zijn over de gebruiksdoelen van zekere informatie. Zo kan een "adres" voor de één de bedoeling hebben om als bezoekadres gebruikt te worden en voor de ander als postadres. +
Op deze pagina willen we een lijst bijhouden met semantische annotaties die we voorzien te gebruiken in de kennishub bij de beschrijving van de architectuur. De bedoeling is om bij het ingeven van initiatieven op de kennishub, de architecturale beschrijving te voorzien van een semantische annotatie zodat in een latere fase hierop gezocht kan worden. Het volgende diagram geeft een overzicht welke termen er op dit moment gebruikt worden en hun relatie.
Onderstaande lijst geeft aan welke annotaties voorzien zijn en wat ze precies betekenen.
Eigenschap
Voorbeeld
Verklaring
Termen
[[term::ICT]]
Een term is een relevant begrip of afkorting
Concepten
[[concept::Context broker]]
Een relevant idee, or verzameling ideeen die gerelateerd zijn: een plan, model of toestanden. Voorbeelden hiervan in de VLOCA zijn zowel meer high level concepten als software architectuur , maar ook meer toegepaste als context broker . [1]
Componenten
[[component::Orion]]
Een component is een software of hardware module met een specifiek doel. Een component is vaak een realisatie van een concept: Orion is een realisatie van een Context Broker .
Standaarden
[[standaard::NGSI-LD]]
Een standaard is een formele afspraak. Deze zorgt ervoor dat verschillende systemen met elkaar kunnen communiceren/samenwerken. Concepten worden een-eenduidig gespecificeerd door Standaarden .
Principes
[[principe::data_souvereiniteit]]
In de context van de kennishub is een principe een obligatoir concept . Een systeem dat VLOCA implementeert moet zich de hier gedefinieerde essentiele concepten houden.
Organisaties
[[organisatie::NEN]]
In de context van de kennishub kunnen dit zowel Organisaties met leden zijn (bv FIWARE) als ook project Organisaties (SynchroniCity).
Smart City Architectuur
[[architectuur::VLOCA]]
...
Bouwlagen
[[bouwlaag::Devices]]
Een bouwlaag wordt gevormd door een aantal Componenten met eenzelfde abstractieniveau: de fysieke bouwlaag wordt gevormd door Componenten die hardware aansturen.
Systeemeigenschappen
[[systeemeigenschap::schaalbaarheid]]
Eigenschappen die specifiek zijn voor een systeem. Voorbeelden hiervan zijn schaalbaarheid ; Een systeem met deze eigenschap kan bijvoorbeeld vrij eenvoudig grotere hoeveelheden data aan.
Cross-cutting concerns
[[cc_concern::Security]]
cross-cutting concerns zijn systeemaspecten die relevant zijn voor het gehele systeem; bekende voorbeelden hiervan zijn security en data integriteit .
Wat is Semi Structured Data?
Semi Structured data is een component van de Data capture bouwlaag. +
Dit is de initiatiefpagina City of Things Sensoc – Gent (veiligheid).
Deze pagina beschrijft het initiatief volgens de definitie op de VLAIO website en linkt door naar relevante pagina's op de kennishub.
[1]
Overzicht City Of Things Initiatieven
Geen resultaten
De Gentse Rabotwijk is een aankomstwijk met een weinig stabiele bevolking. De wijk is superdivers en kent veel kwetsbare bewoners. Onder die bewoners ook een grote groep jongeren. Exacte cijfers zijn te vinden op het dashboard. Op de westelijke sector van de wijk (sector ‘Rabot’) zitten veel bewoners op beperkte oppervlakte gehuisvest in kleine verouderde woningen en minder recente sociale hoogbouw. Cijfers verzameld in de buurtmonitor en aanvullend onderzoek bewijzen dat de bewoners zich niet veilig voelen in hun eigen wijk. Politie bevestigt deze subjectieve meting maar ziet dit niet weerspiegeld in het aantal meldingen. Er is dus zeker sprake van ondermelding. Dit heeft te maken met:
Meldingsmoeheid
Meldingsangst
Wantrouwen tov diensten
Via de objectieve tussenkomst van en ondersteuning door technologie willen we het veiligheidsgevoel op de buurt verstevigen. We zien de sector Rabot als een fieldlab waar we door gerichte inzet van technologie de gevoelens van onveiligheid tackelen. We ontwikkelen, bouwen en implementeren deze via een co‐creatief en participatief traject. Voor het opzetten van het fieldlab en de technologische component van het project betrekken we een partner.
De input die we via mental en digital mapping verkrijgen, verwerken we in een heatmap die gevoelens van (on)veiligheid op de sector visualiseert. Deze dient als input voor het ontwikkelen van minstens drie prototypische usercases ivm ondermelding of direct aanleiding onveiligheid. We ontwikkelen ‘hacks’ met betaalbare, beschikbare en eenvoudige technologie om deze te tackelen. Nadien evalueren we de efficiëntie en doeltreffendheid van de geformuleerde oplossing.
De methodiek om via een fieldlab technologie op maat te ontwikkelen is niet nieuw. Wel de mate waarin we sociale actoren betrekken bij het proces. Daarom werken we nauw samen met diensten en organisaties die de aanwezige doelgroepen ondersteunen. Sinds zomer 2018 werken Stad Gent, VZW Jong en Samenlevingsopbouw Gent er intensief samen. Ze brachten de uitdagingen in kaart en gingen deze aan via concrete acties. Laborabot en tijdelijke invulling El Passant zijn daar voorbeelden van. Deze partners zijn zeer belangrijk binnen de co‐creatieve aanpak die basisonderdeel is van het project.
We willen de klassieke methodieken uitbreiden met technologische innovatie. Via gerichte ingrepen in de bouwvolumes en het openbaar domein kunnen we het veiligheidsgevoel beïnvloeden. Hieronder enkele voorbeelden:
Zintuigbeïnvloeding wordt al ingezet voor marketingdoeleinden. In dit project willen we een
experiment doen met vernieuwende technieken rond licht, geluid en geur: multi‐sensorieel inzetten om het welzijn en veiligheidsgevoel en de veiligheid (dus subjectief + objectief) te verhogen.
Aantrekkelijke en veilige toegangen: slimme technologie zorgt ervoor dat enkel bewoners in de woontorens binnen geraken.
Lokale digitale netwerken opzetten met eenvoudige interface (counteren sociaal isolement).
Mapping van buurt dmv technologie ivm (on)veiligheidsgevoel en inzet van technologie om dit aan te pakken (vb: aansturing verlichting).
Via gamification en nudging het gedrag van de bewoners positief beïnvloeden.
↑ https://www.vlaio.be/nl/vlaio-netwerk/city-things-slimme-steden-en-gemeenten/city-things
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. +
De primaire focus van de Sensor Model Language (SensorML) is om een robuust en semantisch gekoppeld model te bieden voor het definiëren van processen en verwerkings Componenten in verband met de meting en post-metingstransformatie van waarnemingen. Dit omvat zowel sensoren en actuatoren als rekenkundige processen die voor en na de meting worden toegepast. Het hoofddoel is om interoperabiliteit mogelijk te maken, eerst op syntactisch niveau en later op semantisch niveau (door gebruik te maken van ontologieën en semantische bemiddeling), zodat sensoren en processen beter kunnen worden begrepen door machines, automatisch kunnen worden gebruikt in complexe workflows en gemakkelijk kunnen worden gedeeld tussen intelligente sensor-webknooppunten. Deze standaard is een van de verschillende implementatie Standaarden die onder OGC's Sensor Web Enablement (SWE) activiteit worden geproduceerd. Deze standaard is een herziening van de inhoud die eerder werd geïntegreerd in de SensorML versie 1.0 standaard (OGC 07-000).
[[Open Geospatial Consortium (OGC) | Overzicht van OGC Standaarden ›]] +
De Sensor Observation Service standaard is een Open Geospatial Consortium (OGC) [1] standaard die toelaat sensor data te onstluiten. De volledige specifiatie van de SOS standaard is terug te vinden op : https://www.ogc.org/standards/sos
See also Observations and Measurements [2] .
[[Open Geospatial Consortium (OGC) | Overzicht van OGC Standaarden ›]]
↑ https://www.ogc.org/ OGC
↑ https://www.ogc.org/standards/om +
De OpenGIS Sensor Planning Service Interface Standard (SPS) definieert interfaces voor vragen die informatie geven over de mogelijkheden van een sensor en hoe de sensor moet worden getaxeerd. De standaard is ontworpen om vragen te ondersteunen die de volgende doelen hebben:
het bepalen van de haalbaarheid van een sensorplanningsaanvraag; het indienen en reserveren/vastleggen van een dergelijke aanvraag;
het informeren over de status van een dergelijke aanvraag;
het updaten of annuleren van een dergelijke aanvraag;
en het aanvragen van informatie over andere OGC-webdiensten die toegang bieden tot de gegevens die door de gevraagde taak worden verzameld.
Dit is een van de OGC Sensor Web Enablement (SWE)- Standaarden .
[[Open Geospatial Consortium (OGC) | Overzicht van OGC Standaarden ›]] +
Sensordata is data afkomstig van een sensor, vaak gaat het hier om (semi) real-time data. +