DisGeo Demo II Lessons Learned

Geonovum Algemeen
Vastgestelde versie

Deze versie:
https://docs.geostandaarden.nl/disgeo/def-al-dll2-20210107/
Laatst gepubliceerde versie:
https://docs.geostandaarden.nl/disgeo/dll2/
Laatste werkversie:
https://geonovum.github.io/disgeo-demo-2
Redacteur:
Linda van den Brink, Geonovum
Auteurs:
Bart van Leeuwen, Netage
Erwin Folmer, Kadaster
Nicky van Oorschot, Netage
Niels Hoffmann, Provincie Noord-Holland
Pano Maria, Skemu
Doe mee:
GitHub Geonovum/disgeo-demo-2
Dien een melding in
Revisiehistorie
Pull requests
Rechtenbeleid:

Samenvatting

Dit document beschrijft de geleerde lessen die zijn opgedaan tijdens het in 5 dagen ontwikkelen van een demonstrator voor DisGeo. De DisGeo Demo fase 2 toont wat Linked Data voor DisGeo kan betekenen, en wat de tekortkomingen zijn. De nadruk ligt daarbij op integrale gebruiksvragen over datasets heen, gebaseerd op samenhang tussen datasets.

De belangrijkste conclusies zijn:

Veel van de datasets die we gebruiken in de demonstrator zijn wel op basis van linked data standaarden gepubliceerd, maar bevatten geen links naar andere data, ook niet naar bestaande basisregistraties. Op het moment dat die links tussen individuele objecten uit verschillende registraties er wel zijn, wordt werken met de data veel eenvoudiger. Ondersteund door de techniek van linked data werkt samenhang écht, ook tussen officiële overheidsregistraties en private aanvullende registraties. Linked data betekent niet per sé linked OPEN data; en gesloten en open linked data kunnen aan elkaar gekoppeld worden waarbij authenticatie en authorisatie van de gesloten data met standaard web technieken eenvoudig en goed geregeld zijn.De techniek is er klaar voor; organisatorisch moet er nog wel wat gebeuren: het leggen van links tussen objecten vraagt om governance op het snijvlak, i.e. een verantwoordelijke partij die niet alleen de objecten maar ook de links daartussen beheert.

Software voor het opslaan en bevragen van linked data bleek goede ondersteuning te hebben voor geografische linked data. Dit was een aantal jaren nog niet het geval, maar in de tussentijd heeft een professionalisering plaatsgevonden in dit soort software. Ditzelfde zien we ook in overige linked data tooling: er is goede tooling beschikbaar voor het bewerken, browsen etc en deze tooling werkt volledig interoperabel. Dit is een belangrjike constatering, want hoewel het altijd de belofte van datastandaarden is geweest dat er interoperabiliteit mee bereikt wordt, werd dat in de praktijk nooit volledig waargemaakt. In dit geval wel. Gezien de goede ondersteuning in de markt kunnen we stellen dat linked data er klaar voor is om in serieuze projecten met geografische data ingezet te worden.

Status van dit document

Deze paragraaf beschrijft de status van dit document ten tijde van publicatie. Het is mogelijk dat er actuelere versies van dit document bestaan. Een lijst van Geonovum publicaties en de laatste gepubliceerde versie van dit document zijn te vinden op https://www.geonovum.nl/geo-standaarden/alle-standaarden.

Dit is de definitieve versie van de algemeen. Wijzigingen naar aanleiding van consultaties zijn doorgevoerd.

1. Introductie

1.1 Context

Het ministerie van BZK beoogt met het traject Doorontwikkeling in Samenhang (DISGeo) meer samenhang te krijgen in het stelsel van geo(basis)registraties waarbij de focus ligt op semantische harmonisatie van registraties en informatiemodellen, en alternatieve methoden van gegevensuitwisseling en bijhouding (meer centraal, minder kopiëren).

Om te onderzoeken hoe dit doel het beste bereikt kan worden zijn verschillende demonstrators ontwikkeld. Over de eerste demonstrator, uit 2019, is een rapport met lessons learned gepubliceerd [DLL1]. De nadruk lag in die fase op het onderzoeken wat er mogelijk is met de huidige stand van de techniek die nu breed wordt toegepast (gebaseerd op API’s). De tweede demonstrator onderzoekt juist vanuit de gewenste uiteindelijke situatie wat er mogelijk is. De bevindingen uit deze tweede demonstrator worden beschreven in dit document.

Het is de bedoeling dat

1.2 De demo

De DisGeo Demo, fase 2, is ontwikkeld van 8 - 14 juli 2020 in een High 5 setting door Kadaster, Provincie Noord-Holland, Netage, IHW, en Geonovum in opdracht van BZK. De demo toont wat Linked Data voor DisGeo kan betekenen.

Een High 5 is een soort 5 dagen lange innovatiesprint, waarbij ontwikkelaars samen in korte tijd bepaalde use cases implementeren in een demonstrator. Het verschil met een gewone sprint is dat een High 5 innoverend en inspirerend is: 'je mag verrast worden'.

1.3 Doel

De DisGeo Demo fase 2 toont wat Linked Data voor DisGeo kan betekenen, en wat de tekortkomingen zijn. De nadruk ligt daarbij op integrale gebruiksvragen over datasets heen, gebaseerd op samenhang tussen datasets.

In 2019 is de DisGeo Demonstrator fase 1 ontwikkeld, waarbij we er tegenaan liepen dat het wel mogelijk, maar om meerdere redenen niet ideaal is om API's aan elkaar te knopen en op die manier integrale vragen over datasets heen te kunnen stellen [DLL1]. Daarom besloten we een tweede versie van de demonstrator te maken die het ideaalplaatje concreet maakt zodat daarmee:

En daarmee ook

1.4 Resultaten

2. Use cases

2.1 Brandweer case Rotterdam

Relevant gebied – regio Rotterdam

Er woedt een grote brand in een pand ergens in Rotterdam. Om de brand zo goed mogelijk te kunnen bestrijden en de gevolgen voor de omgeving te beperken, moet er allerlei informatie verzameld worden.

  1. Tijdens de brand wil de brandweer alles weten wat relevant is, op een overzichtelijke manier.
  1. Achteraf wordt er een impactanalyse gedaan: wat was de geschatte impact van de brand; hoeveel bedrijven moesten ontruimd worden; is er verkeershinder geweest en wt was de economische schade daarvan, hoe lang duurde dat, wat is de milieuschade, etc.
Noot

2.2 Brandweer bluswater case Castricum

Relevant gebied – Castricum

Er is een brand op een locatie in Castricum. Brandweer is ter plaatse en er wordt volop geblust.

Als het blussen lang duurt, ontstaan er vragen over de beschikbaarheid van het bluswater:

De andere grote vraag is waar het gebruikte bluswater naar toe gaat. Meestal gaat het om veel water dat bovendien vaak vervuild is, bijvoorbeeld met chloride of asbestdeeltjes. Hierbij speelt:

Deze use case demonstreert het koppelen van eigen, gesloten data aan basisregistratie data. In dit geval zijn dit de beheer openbare ruimte (BOR) objecten, ook wel areaaldata, van de Provincie Noord-Holland, die via een link verbonden zijn aan de corresponderende BGT objecten, en via de BGT uiteindelijk aan de GWSW rioolnetwerkdata. In de data story is vooral de vraag *"waar stroomt het gebruikte bluswater naar toe"* uitgewerkt.

Voordeel van de beschikbaarheid van deze informatie in samenhang:

3. Data

Er zijn allerlei verschillende databronnen gebruikt in de demonstrator. Sommmige daarvan zijn al beschikbare productiedata of waren al eerder ten behoeve van experimenten geproduceerd, andere zijn ter gelegenheid van deze demonstrator als linked data gepubliceerd.

Selectiecriteria voor de data:

Het verzamelen en prepareren van de data is in de weken voorafgaand aan de High 5 grotendeels al gedaan. Om 14:45 op dag 1 van de High 5 is alle data die nodig is voor de demonstrator redelijk compleet. Dit ging sneller dan bij eerdere soortgelijke experimenten.

Datasets waarbij is aangegeven dat ze via Kadaster Labs beschikbaar zijn, zijn te vinden op de Kadaster Labs DISGeo landingspagina, ook te bevragen via het SPARQL endpoint. Op de landingspagina is beschreven welke gegevens per dataset beschikbaar zijn en onder welke licentie deze eventueel te gebruiken is.

BAG data hebben we via https://bag.basisregistraties.overheid.nl/sparql gebruikt.

Verder hebben we gebruikt:

4. Tools

De volgende tools zijn ingezet voor de demonstrator.

4.1 Ontodia

Ontodia is een linked data viewer waarmee je zowel datamodelen als data kunt visualiseren. Deze tool maakt mooi zichtbaar hoe je door samenhangende data heen kan browsen. Bijzonder hierbij is dat de data niet op één plek hoeft te staan. Je kunt, als er maar links tussen datasets aangebracht zijn, naadloos van object naar object browsen ongeacht in welke datasets deze objecten staan.

Je kunt hier de in de demonstrator gebruikte data bekijken in Ontodia.

4.2 3D viewer

Deze viewer toont een interactief 3D model van Rotterdam van waaruit je met SPARQL access informatie kunt opvragen uit DisGeo bronnen. Je kunt zo de kracht van een GIS systeem (de 3D viewer is gebaseerd op ArcGIS) combineren met de kracht van linked data waardoor je administratieve gegevens kunt integreren met geodata.

4.3 Data stories

Data stories zijn een medium dat het Kadaster Science team gebruikt om verhalen rondom data te vertellen. Een data story combineert interactieve datavisualisaties met toelichtende tekst. De datavisualisaties zijn altijd gebaseerd op actuele data omdat deze gebruik maken van SPARQL bevragingen.

4.4 Analytics tool

Voyager. Voyager is een javascript library voor data visualisatie die met CSV output van SPARQL query kan werken. Deze wordt in de Rotterdam use case toepast voor de 'analyse achteraf' stap.

4.5 Visual SPARQL Builder

Deze tool maakt het zelf maken van SPARQL queries eenvoudiger met een user interface.

In combinatie met Ontodia kan dit een krachtige tool zijn. Als je in Ontodia een interessant gegevenspatroon hebt gevonden, kun je dit omzetten naar een query, die je met behulp van de Visual Query Builder kunt parameteriseren en dan loslaten op een dataset om vergelijkbare data te vinden. Op basis hiervan kun je dan bijvoorbeeld weer rapporten maken.

4.6 RML en R2RML

RML en R2RML zijn de specificaties die gebruikt worden om een mapping te beschrijven om JSON, XML, CSV en databases om te zetten naar RDF formaat. Er zijn tools beschikbaar die het mogelijk maken om deze mappings uit te voeren. Binnen deze high-five zijn CARML en LinkedDataFactory (Wordt binnenkort geopensourced) gebruikt.

4.7 XRM

Om mappings te maken in RML zodat bestanden omgezet kunnen worden naar linked data formaat (rdf) is de tool Expressive RDF Mapper gebruikt. XRM werkt met een "domain specific language" en bevat een simpele syntax die binnen Eclipse gebruikt kan worden om een mapping vorm te geven en vervolgens geautomatiseerd de volledige mapping uitwerkt. Hierdoor worden mapping beheersbehaar en makkelijk op te bouwen en aan te passen.

4.8 Overig

Eventueel toetje: KOOPjs in combinatie met ArcGis StoryMaps. Deze laatste kan nu ook met data werken die niet in ArcGis zit, maar die je live uit een SPARQL endpoint haalt.

5. De Lessons Learned

Tijdens het ontwikkelen van de demonstrator is er veel geleerd. Dit zijn belangrijke inzichten voor de verdere ontwikkeling van DiSGeo en voor diverse standaardenactiviteiten. Wat goed bleek te werken, en wat (nog) niet, wordt in dit hoofdstuk beschreven.

5.3 Linksetjes... snel gemaakt, maar niet beheerd

Er zijn tijdens de High 5 meerdere linksets gemaakt, bijvoorbeeld tussen scholen uit de Duo dataset en BAG verblijfsobjecten en tussen Rijksmonumenten uit de RCE dataset en kadastrale percelen. Dat is, bij een dataset van beperkte omvang, vrij eenvoudig te doen met behulp van een SPARQL query, als er hiervoor maar aanknopingspunten in de data zijn. Het eerste 'linksetje' verscheen al tijdens de eerste uurtjes van de High 5.

Zulke linksets worden echter vaak eenmalig gemaakt op basis van een query. Terwijl de desbetreffende links, die relaties tussen objecten vastleggen, eigenlijk in de data zouden moeten zitten en beheerd worden. De data wijzigt immers voordurend. Bovendien zou de kwaliteit van belangrijke links, zeker links van en naar basisregistraties, de verantwoordelijkheid van een data eigenaar moeten zijn. Dit beheer en eigenaarschap is er echter meestal niet, want wie is verantwoordelijk voor de linkset? Wie beheert de links en betaalt daar dus ook voor?

Er zijn tegenwoordig al aardig wat als linked data gepubliceerde (overheids- geo-) datasets in Nederland. Maar deze data is vrijwel nooit gelinkt aan andere datasets! Het gaat in andere woorden veelal om vier sterren, geen vijf sterren linked data - de vijfde ster betreft namelijk het gelinkt zijn van de data.

Er zijn maar enkele voorbeelden die we kennen van een beheerde linkset tussen basisregistraties; tussen de BRT en de BAG, de BRK en de BAG en de BGT en de BAG.

De linkset tussen de BRT en de BAG is een goed voorbeeld van een koppeling tussen twee datasets waarvan het beheer tegenwoordig geregeld is. Als onderdeel van het werkproces rondom het actualiseren van BRT data wordt ook gekeken naar de BAG panden, met als resultaat relaties tussen BRT objecten en gerelateerde BAG panden. Deze links werden tot voor kort echter weer weggegooid; tegenwoordig wordt deze informatie doorgespeeld aan het Kadaster data science team dat de linkset tussen BRT en BAG publiceert en actueel houdt.

Tijdens de High 5 gemaakte linksets:

Bij de vorige DISGeo demontrator kwam dit punt ook al naar voren: zie de uitleg in governance op het snijvlak. Het is noodzakelijk dat niet alleen de objecten uit basisregistraties (en ook andere registraties), maar ook de links tussen objecten (relaties) beheerd worden. Zoals een toeschouwer van de einddemo op de laatste dag van de High 5 opmerkte: Het moet voor de gebruiker duidelijk zijn met welke actualiteit hij/zij werkt. Dit geldt ook voor de relaties die er tussen objecten zijn gelegd, want deze zijn gevoelig voor verandering als objecten veranderen. In de high 5 liepen we niet expliciet tegen problemen met actualiteit aan, maar we nemen dit punt wel mee in ons verdere werk voor DiS Geo.

5.4 Uniforme referentie naar basisregistraties

In de huidige praktijk is er gebrek aan eenduidigheid bij het refereren naar objecten uit basisregistraties, vanuit een eigen dataset of door basisregistraties onderling. Dit probleem is eerder al onderkend tijdens een linked data onderzoek in INSPIRE context.

Internationaal is er een gestandaardiseerd lijstje van linksoorten om te linken van het ene geo-object naar het andere (denk aan within, touches, contains). Dit is beschreven in Spatial Data on the Web Best Practice 10: Use appropriate relation types to link Spatial Things.

Wat echter nog ontbreekt, is een gestandaardiseerde property waarmee partijen kunnen linken naar objecten in basisregistraties, op zo'n manier dat gebruikers kunnen zien dat het naar een basisgegeven linkt. Zo'n property zou gestandaardiseerd moeten worden in de DISGeo vocabulaire onder bijvoorbeeld de naam: disgeo-object-ref of basisgegeven-ref.

We vragen ons nog wel af of zo'n generieke verwijzing voldoende is, of dat wilt kunnen zien naar wat voor soort object de link verwijst. Bijvoorbeeld: disgeo-pand-ref, disgeo-kunstwerk-ref. Overwegingen hierbij:

Er zijn ook andere standaarden die dit soort linknamen definiëren, bijvoorbeeld:

Een gestandaardiseerde disgeo-object-ref staat niet in de weg van het gebruik van deze andere standaarden. Het is geen enkel probleem, sterker nog het verhoogt juist de interoperabiliteit, om in deze gevallen twee keer de link te leggen: één keer met behulp van de door DisGeo gestandaardiseerde link, en één keer met de link uit de andere standaard.

Noot

5.5 Open en gesloten linked data

Hoe koppel je open en gesloten knowledge graphs aan elkaar? Afhankelijk van wat je linked data opslagsysteem (oftwel triple store) kan is het tegenwoordig al mogelijk om ofwel op graph (dataset) niveau, ofwel op objectniveau in te stellen op basis van welke voorwaarden gebruikers de data mogen ontvangen.

Twee belangrijke use cases hiervoor zijn:

In de demonstrator hebben we dit niet uitgebreid laten zien, juist omdat het al eenvoudig is om dit te doen. Het is wel een belangrijk punt om je te realiseren: linked data betekent niet per sé linked OPEN data; en gesloten en open linked data kunnen aan elkaar gekoppeld worden waarbij authenticatie en authorisatie van de gesloten data met standaard web technieken eenvoudig en goed geregeld zijn.

5.7 Ruimtelijke vragen in linked data nu beter ondersteund

GeoSPARQL [geosparql] is de standaard querytaal voor het ruimtelijk bevragen van linked geodata. Onze ervaringen tijdens deze high 5 lieten zien dat vergeleken met 2 á 3 jaar geleden de ondersteuning voor GeoSPARQL enorm verbeterd is, zowel wat betreft compliance aan de standaard, als wat betreft performance. Er heeft een verschuiving plaatsgevonden van academische implementaties naar commerciële.

De meeste triple stores die GeoSPARQL support hebben, bieden:

De volgende tabel geeft voor een aantal gangbare triple stores aan of ze voldoen aan de GeoSPARQL standaard en hoe de performance is wat betreft ruimtelijke vragen.

product compliance performance
GraphDB ja redelijk, maar met grote datavolumes zoals die van de basisregistraties niet toereikend
Stardog ja ja
Virtuoso ja ja
MarkLogic nee ja
parliament verouderd onbekend

De performance van GeoSPARQL-ondersteunende triple stores kan getest worden met deze dataset for benchmarking GeoSPARQL.

5.8 Wanneer GeoSPARQL, wanneer GIS

In de geowereld hebben we natuurlijk al lang de mogelijkheid om ruimtelijke vragen te stellen. Maar gegeven de beschikbaarheid van geo linked data, wanneer is het dan beter om GeoSPARQL te gebruiken, en wanneer een GIS? Je kunt je dit voorstellen als een tweetrapsraket. Vaak is er, om een ruimtelijk probleem op te lossen, eerst een selectie nodig van allerlei relevante data in een bepaald gebied. Data, die in verschillende systemen staat. Vervolgens wordt op die dataverzameling nadere analyse gedaan om de gestelde vraag te beantwoorden. In zo'n geval spelen zowel GeoSPARQL als GIS een cruciale rol:

Met andere woorden, geo-linked data en GIS zijn complementair.

5.9 GeoSPARQL in federatieve queries

Bij het gebruik van GeoSPARQL is er nog wel een technische beperking. Eén van de sterke punten van linked data is het kunnen bevragen van meerdere data endpoints binnen één query, waardoor je in één stap informatie kunt halen uit meerdere registraties. Je kunt, simpel gezegd, aan een triple store vragen:

"Geef mij het BGT object Wegdeel met id 12345 en zoek ook even bij dit andere endpoint op wat er nog meer over dit wegdeel bekend is"

Als je hierbij echter een geovraag wilt stellen (bijvoorbeeld: welke putten uit endpoint GWSW vallen binnen het polygoon van wegdeel Y uit endpoint BGT?) is dat nog maar zeer beperkt mogelijk. Tussen 2 endpoints van dezelfde vendor, bijvoorbeeld twee Virtuoso endpoints, werkt het mogelijk nog wel, maar tussen 2 endpoints van verschillende triple store producten niet. Hier laat de interoperabiliteit ons dus in de steek. Een mogelijke verklaring hiervoor is dat de endpoints alleen geovragen willen beantwoorden waarbij de objecten in de eigen ruimtelijke index staan.

Om te bewerkstelligen dat vendors dit mogelijk gaan maken, moet er in de GeoSPARQL standaard een aanbeveling komen over het ondersteunen van geovragen in federatieve queries. GeoSPARQL is ouder dan SPARQL 1.1, waarin federatie geregeld is.

In de demonstrator liepen we hier tegenaan bij de Castricum use case, en is dit opgelost door de gewenste query in stukken te knippen met een linkset tussen BGT en GWSW.

5.10 Een adres is nog geen locatie

Bij objecten die een adres hebben, of aan een BAG verblijfsobject gekoppeld zijn, blijkt dit niet altijd te betekenen dat het object zich ook daadwerkelijk op dit adres bevindt. Pas dus altijd goed op hoe je dit interpreteert, en verifieer zo goed mogelijk wat er precies bedoeld wordt met een adreskoppeling.

Onze aanbeveling is om in DISGeo goed vast te leggen wat er precies wordt bedoeld met adreskoppelingen of andere indirecte koppelingen met een locatie. Betekent dit dat het object zich daadwerkelijk op die locatie bevindt? Of is het niet meer dan een administratieve aanduiding? Ook objecten met een indirecte koppeling aan een locatie kunnen dan in ruimtelijke vragen gebruikt worden, terwijl objecten met een administratieve locatieaanduiding daarbij niet meegenomen worden.

Bovendien zou het zinnige verrijking zijn om de daadwerkelijke locaties van objecten, waar dit van toepassing is, zo veel mogelijk op te nemen, naast eventuele administratieve aanduidingen zoals een postadres. Met een herkenbare link uiteraard.

5.11 Geen vendor lock in!

Tijdens de High 5, en ook tijdens het schrijven van deze Lessons Learned, waren we al snel zo lekker op dreef dat we ons op dag vier pas deze les realiseerden:

We hadden helemaal geen afspraken vooraf gemaakt over de te gebruiken tooling en versies daarvan. En tóch werkte alles.

Het feit dat we linked data standaarden gebruikten, en dat willekeurig welke tooling deze standaarden blijkbaar zonder ambiguiteiten ondersteunt, maakte het mogelijk dat we gewoon aan de slag konden met de toolset van onze voorkeur en daarbij geen enkel interoperabiliteitsprobleem ondervonden hebben. Dit is een belangrjike constatering, want hoewel het altijd de belofte van datastandaarden is geweest dat er interoperabiliteit mee bereikt wordt, werd dat in de praktijk nooit volledig waargemaakt. In dit geval wel!

5.12 Samenhang werkt echt

Door het op de juiste manier doorvoeren van de links, in de tijdens de High 5 gerealiseerde linked data variant van de basisregistraties (de knowledge graph), is de waarde van de links direct zichtbaar te maken. Met een combinatie van de juiste tooling en de juiste standaarden hebben we gezien dat bevragen van basisregistraties over hun silo grenzen heen prima werkt. De relaties tussen objectinstanties in bijvoorbeeld de WOZ, BAG en BRK zijn direct inzichtelijk te maken zonder de noodzaak om alle data in één systeem te laden.

Als een organisatie een interne, gesloten dataset gebruikt die volgens de standaarden refereert aan een basisregistratie is de koppeling direct bruikbaar waardoor de interne dataset direct verrijkt kan worden met gegevens uit de basisregistratie. Dit is te zien in de Castricum use case.

Zoals genoemd in één van de lessons learned, Uniforme referentie naar basisregistraties, kan de relatie met de basisregistratie ook dienen als kwaliteitscheck voor de interne data.

Noot

5.13 Hoe nu verder

Tenslotte plaatsen we bij het succes van deze High 5 de volgende kanttekening. De deelnemers aan deze vijf dagen waren, zoals één van hen zei, waren de 'crème de la crème' van de Nederlandse linked data community. We gingen uit van een te realiseren 'ideaalplaatje', dat we met behulp van linked data standaarden en tooling hebben weten te realiseren. Alles wat we bereikt hebben, is mede te danken aan de expertise die er deze week aan tafel zat. Dit laat zien dat de mogelijkheden bijna onbegrensd zijn, en dat met behulp van linked data de DISGeo ambities te realiseren zijn bij de huidige stand van de techniek, mits er voldoende kennis aanwezig is.

We zouden een soortgelijk experiment eigenlijk nog een keer moeten herhalen met ontwikkelaars die minder linked data kennis hebben.

A. Referenties

A.1 Normatieve referenties

[DLL1]
DisGeo Demo Lessons Learned. Geonovum. 2020-02-19. Definitief. URL: https://docs.geostandaarden.nl/disgeo/dll/
[geosparql]
GeoSPARQL - A Geographic Query Language for RDF Data. Matthew Perry; John Herring. OGC. 10 September 2012. URL: http://www.opengeospatial.org/standards/geosparql
[sdw-bp]
Spatial Data on the Web Best Practices. Jeremy Tandy; Linda van den Brink; Payam Barnaghi. W3C. 28 September 2017. W3C Note. URL: https://www.w3.org/TR/sdw-bp/
[vocab-ssn]
Semantic Sensor Network Ontology. Armin Haller; Krzysztof Janowicz; Simon Cox; Danh Le Phuoc; Kerry Taylor; Maxime Lefrançois. W3C. 19 October 2017. W3C Recommendation. URL: https://www.w3.org/TR/vocab-ssn/