UNGEGN - Geographical Names in the KKG

Created a day ago

With this data story, we would like to demonstrate the range of ways in which geographical names in the context of the Netherlands have been included and can be identified in the Kadaster Knowledge Graph (KKG). For a complete overview of the modelling and development approach taken in developing the Kadaster Knowledge Graph, please visit the Kadaster Data Science Team's lab environment.

Analyse BGT terugmeldingen

Created 7 days ago

figure 1. "Key worden" voor object type.

GeoE3 Project Task 2.4 Demo Environment

Created a month ago

Introduction

The following environment serves to both outline the requirements and processes required to improve search engine findability for datasets housed in a national geoportal catalogue. In general, a search engine is able to find information more easily when metadata about the information is indexable by the search engine itself. Making a webpage indexable requires that metadata is embedded into the HTML header of a webpage and is making use of the schema.org vocabulary. For datasets specifically then, the metadata which already exists for a given dataset in catalogues, for example, could be used in the headers of webpages to improve the findability of that dataset in a search engine. This requires the implementation of various process steps as will be demonstrated here.

As a demonstration environment, the process described below was tested and has been implemented within the context of Kadaster, the Dutch National Mapping Agency. Although the results are transferable to other environments, the process described below would likely require some adaptation when implemented in a different context.

Data Model Kadaster Kennisgraaf

Created a month ago

Deze pagina documenteert het volledige data model van de Kadaster Kennisgraaf.

1. Download opties

Het data model van de Kadaster Kennisgraaf kan op verschillende manieren gedownload worden:

  • Alleen de concepten (SKOS), voor gebruik in ArchiXL: link
  • Alleen de klassen en eigenschappen (RDFS/OWL), voor gebruik in Weaver: link
  • Alleen de shapes (SHACL): link

2. Data model structuur

Ieder gegeven in het data model van de Kadaster Kennisgraaf is op 3 niveau's vastgelegd. Deze 3 niveau's staan met elkaar in verband:

  1. Node shapes en property shapes (SHACL) geven de beperkingen aan waar de gegevens in de Kadaster Kennisgraaf aan voldoen. Deze beperkingen zijn altijd consistent met de betekenis zoals vastgelegd in de klassen en eigenschappen, maar kunnen op onderdelen strikter zijn.
  2. Klassen en eigenschappen (RDFS/OWL) leggen de formele betekenis vast. Deze betekenis legt vast wat andere applicaties en gebruikers op het Internet mogen verwachten wanneer ze de gegevens uit de Kadaster Kennisgraaf gebruiken.
  3. Concepten (SKOS) leggen de menselijk leesbare betekenis vast.

Het volgende diagram geeft aan hoe deze 3 niveau's met elkaar in verband staan.

3. Document structuur

De rest van dit document volgt een vaste structuur voor klassen en eigenschappen. Deze worden vastgelegd in secties A (NEN3610:2022nl), B (Samenhangende Object Registratie), en C (Kadaster-breed model).

3.1 Document structuur voor klassen

Klassen worden beschreven in de volgende subsecties:

  1. Linguïstische duiding bevast de menselijk leesbare definities, voorbeeld, en gebruiksnotities. Deze gegevens zijn in lijn met de menselijk leesbare vastlegging voor deze klasse (SKOS).
  2. Schematische weergave geeft een overzicht van de taxonomie voor deze klasse, alsook de eigenschappen die deze klasse als domein hebben.
  3. Formele duiding geeft een beschrijving in het RDF Turtle formaat van de machine-leesbare gegevens die voor deze klasse zijn vastgelegd in SHACL en in RDFS/OWL.
  4. Eigenschappen geeft een tabel met een overzicht van de eigenschappen die deze klasse als domein hebben.

3.2 Document structuur voor eigenschappen

Eigenschappen worden beschreven in de volgende subsecties:

  1. Linguïstische duiding bevat de menselijk leesbare definities, voorbeeld, en gebruiksnotities. Deze gegevens zijn in lijn met de menselijk leesbare vastlegging voor deze eigenschap (SKOS).
  2. Schematische weergave geeft een overzicht van de directe context van deze eigenschap binnen het data model.
  3. Formele duiding geeft een beschrijving in het RDF Turtle formaat van de machine-leesbare gegevens die voor deze eigenschap zijn vastgelegd in SHACL en in RDFS/OWL.

4. Geautomatiseerde overzichten

Hieronder volgen een aantal automatisch aangemaakte overzichten op basis van het volledige data model van de Kadaster Kennisgraaf. Voor meer detail kan gebruik worden gemaakt van de uitgebreide documentatie per klasse en per eigenschap die na deze automatische overzichten volgt.

GeoSPARQL Compliance/Performance Uitdagingen [NL]

Created a month ago

Performance

Er zijn verschillende performance uitdagingen op de huidige versie van onze Linked Data bronnen. Deze tonen we hieronder.

Thema 1: Geo-Performance

Er zijn verschillende queries die een slechte geo-spatiële performance hebben. Deze kunnen we onderscheiden in twee problemen:

  • slechte performance qua tijd.
  • inaccurate resultaten.

We kijken eerst naar slechte performance in tijd. Wanneer een andere gemeente (i.e. geen caching) of een groter limiet wordt gekozen komen er meteen grote problemen naar boven.

Metadata Quality Check

Created a month ago

Om de vindbaarheid en volledigheid van PDOK-metadata te verbeteren, is het van belang dat de kwaliteit van de metadata goed is. Dit kan in twee delen. Ten eerste moeten de door PDOK gepubliceerde metadata voldoen aan de relevante standaarden. Ten tweede moet de kwaliteit van de metadata ook voldoen aan de praktische vereisten (zoals Google's Rich Results Test) om doorzoekbaarheid en vindbaarheid te garanderen. De volgende vragen laten zien waar verbeteringen mogelijk zijn in termen van zowel de standaarden als de praktische vereisten voor metadata.

Standards Metadata Vereisten (ISO19115 and ISO19119)

Onderstaande figuren belichten enkele tekortkomingen in de metadata voor vereisten met betrekking tot brontalen, trefwoordenen onderwerpen. Hieronder volgen ook voorbeelden van vereisten waaraan momenteel niet wordt voldaan in de metdata, omdat deze gevallen niet worden gedefinieerd door een vocabulaire, schema.org of anderszins.

LADM Code List: Summary Documentation

Created a month ago

The following documentation was drafted as a summary to an earlier implementation document proposing the following metamodel for the implementation of semantically enriched code lists. The figures and documentation that are contained within this document serve only as a summary for discussion within the workshop given as part of the 10th Annual Land Administration Domain Model Workshop. The full paper drafted and submitted to this workshop can be found here.

LADM Code List Metamodel Demo

by LADM
Created a month ago

The following document provides some insight into the types of questions related to LADM code lists that can be answered following full implementation of the metamodel proposed here.

In each section of this document, a question or task is defined based on which a SPARQL query is defined and performed with the results answering the question or the task. The SPARQL query is being performed on a dataset containing code lists (and their various attributes) and code list values (and their attributes) which are structured according to the metamodel defined. Please note, that all data used in this demonstration is fake in that it does not represent data related to existing code lists. If you would like to see the underlying SPARQL query or interact with the dataset itself, please follow the 'Try this query yourself' link to see the query and click on the 'Dataset' link at the top of the query to see the raw data.

Windturbines in Nederland

Created 3 months ago

Hoe veel windturbines zijn er in Nederland? En welke eigenschappen hebben ze? Het Kadaster heeft informatie over windturbines, maar deze informatie is op dit moment nog verspreid over verschillende registratiesystemen. In deze data story beproeven we of het mogelijk is om met linked data een geïntegreerd beeld over verschillende bronsystemen heen te tonen.

Data story voor planologen - per buurt

Created 3 months ago

Planologen en stedenbouwers houden zich bezig met wat mensen waar kunnen doen en hoe dat kan veranderen.

Daarvoor hebben ze geodata nodig, zoals

  • Locatie en oppervlakte van gebouwen en terreinen.
  • Type gebouw of terrein.
  • Functie of gebruiksdoel van een gebouw of een terrein.

Ze willen ook vragen stellen over combinaties en selecties, zoals “totale oppervlakte van alle gebouwen met een sportfunctie”.

Alle onderstaande bevragingen gaan uit van een buurt als geografische afkadering tbv een analyse. Voor een identieke data story waarin over woonplaatsen wordt geredeneerd, zie deze data story.

Waarom een IGO?

Created 3 months ago

1. Waarom een IGO?

De behoefte om gebruik te maken van gecombineerde data uit verschillende basisregisters is groot, maar momenteel moeilijk door manier waarop de basisregistraties zijn ingericht en de complexiteit van de bijbehorende gegevensmodellen. De IGO is een eerste oplossing voor dit vraagstuk van geïntegreerd gebruik en biedt de mogelijkheid om op een geïntegreerde manier gebruik te maken van data uit meerdere geo-basisregistraties. Deze IGO oplossing is generiek, dus niet gemaakt om een specifiek probleem voor een bepaalde sector op te lossen, maar een oplossing biedt voor oneindig veel vragen die leven bij verschillende gebruikers in verschillende sectoren.

Nutsbedrijven

Created 3 months ago

De nutsbedrijven staan voor grote uitdagingen om hun netten in een steeds voller wordende gebouwde omgeving in te passen. Eenvoudig te gebruiken betrouwbare, digitale informatie over de inrichting van de omgeving is voor het efficiënt plannen, realiseren en beheren onontbeerlijk.

De integrale gebruiksoplossing vereenvoudigt het gebruik van de data uit de verschillende geo-basisregistraties.

De volgende data story maakt gebruik van de integrale gebruiksoplossing om een gegeven reeks vragen te beantwoorden die gebruikelijk zijn in de sector nutsbedrijven.

Knowledge Graph Demo

Created 3 months ago

Alle informatie integraal

Voor gebouwen is er momenteel heel wat informatie beschikbaar:

  • Adresgegevens (BAG)
  • Bouwjaar (BAG)
  • Oppervlakte (BAG)
  • Gebruiksdoel(en) (BAG)
  • Type Gebouw (BRT)
  • Geometrie (BAG, BRT, BGT)
  • Buurt/Wijk/Gemeente waarin gelegen (CBS)
  • Bijbehorende kerncijfers (CBS)
  • Gerelateerde Percelen (BRK Adressen)
  • Perceelgrootte & Geometrie (DKK)
  • Eventuele publieksrechtelijke Beperkingen (BRK-PB)

Beheer Openbare Ruimte

Created 3 months ago

Buurten binnen een Gemeente

Veel bevragingen die gaan over het beheer van de Openbare ruimte vinden plaats op buurt-niveau. Daarom is het van belang om te weten welke buurten er binnen een gemeente beschikbaar zijn. Dat kan met de volgende live bevraging.

BGT Wegwerkzaamheden

Created 3 months ago

De Basisregistratie Grootschalige Topografie (BGT) kan voor verschillende use cases gebruikt worden. En voorbeeld van zo'n use case is wegonderhoud. Wanneer onderhoud aan wegen plaatsvind is er vaak de behoefte om omwonenden daarvan op de hoogte te stellen. Omdat alle wegdelen in Nederland in de BGT worden geregistreerd kan aan het begin van een onderhoudstraject een uitdraai gemaakt worden van de adressen die moeten worden aangeschreven. Dit wordt in Figuur 1 getoond.

Points of Interest: BRT Bunkers

Created 3 months ago

Het is een overzicht van alle bunkers die in het BRT staan

BRK BAG Analyse

Created 3 months ago

Huidige problematiek BRK-BAG Koppeling

Er zijn momenteel een aantal uitdagingen met de bestaande BAG-BRK koppeling die we proberen inzichtelijk te maken. Hierbij zullen we ons focussen op de volgende thematieken.

  • KBI Adressen en de oplopende trend hiervan
  • Koppelingen die zijn aangemaakt in de "Vermenigvuldigingsproblematiek"
  • Foutieve koppelingen vanwege foute puntcoördinaten in de BAG
  • Misplaatste adressen (Perceel en adres liggen te ver uiteen)

Data story voor planologen - per woonplaats

Created 3 months ago

Planologen en stedenbouwers houden zich bezig met wat mensen waar kunnen doen en hoe dat kan veranderen.

Daarvoor hebben ze geodata nodig, zoals

  • Locatie en oppervlakte van gebouwen en terreinen.
  • Type gebouw of terrein.
  • Functie of gebruiksdoel van een gebouw of een terrein.

Ze willen ook vragen stellen over combinaties en selecties, zoals “totale oppervlakte van alle gebouwen met een sportfunctie”.

Alle onderstaande bevragingen gaan uit van een woonplaats als geografische afkadering tbv een analyse. Voor een identieke data story waarin over CBS buurten wordt geredeneerd, zie deze data story.

Totale gebruiksoppervlakte binnen een woonplaats

Stel, in een gebied wordt gestreefd naar een vergroting van de mogelijkheden van de bevolking om het hele jaar door sportief actief te zijn en te blijven.

Een indicatie van die mogelijkheden kun je krijgen door in beeld te brengen waar je kunt sporten. Voor het restant van deze data story zullen we inzoomen op de specifieke vraag rondom deze doelstelling (meer sporten), maar zullen we de queries dusdanig generiek opstellen dat verschillende analyses kunnen worden uitgevoerd.

Het is mogelijk te vragen naar de “totale oppervlakte van alle gebouwen met een sportfunctie”:

Algemene Queries voor KKG gebruik

Created 3 months ago

De volgende data story is bedoeld om de gebruiker te ondersteunen bij het gebruik en de navigatie van de Kadaster Knowledge Graph (KKG). Deze generieke query's hebben twee doelen:

  • De generieke query's die hier zijn opgenomen, dienen om te illustreren hoe de schema.org-ontologie, die wordt gebruikt bij de modellering van het data model voor de knowledge graph, wordt toegepast om de data uit bestaande basisregistraties gemakkelijker beschikbaar te stellen.

  • Deze query's ondersteunen gebruikers door een eerste stap te bieden voor het opvragen van data op basis van verschillende eigenschappen in de knowledge graph. Het is de bedoeling dat deze queries een startpunt vormen voor gebruikers waarop ingewikkeldere queries gebouwd kunnen worden.

Adres en geometrie gerelateerd aan adressen op de kaart

De volgende zoekopdracht retourneert adresinformatie, inclusief straatnaam, postcode en woonplaats van een bepaalde plaats en plot deze op de kaart op basis van BAG-geometrie. Als u op de geometrie klikt, wordt de adresnaam voor een bepaalde plaats weergegeven. Met de invoerparameter kan de gebruiker adresgegevens opvragen binnen een bepaalde postcode.

Merk op dat deze bevraging gebruik van een API variabele, namelijk "postcode". Het is mogelijk om een of meer van dit soort API variabelen bovenop een SPARQL bevraging te configureren. De door een gebruiker ingevulde postcode wordt automatisch door de SPARQL engine in de bevraging ingevoegd en uitgevoerd. Hierdoor is het mogelijk om een SPARQL bevraging op bepaalde onderdelen aan te passen zonder dat hiervoor gedetailleerde kennis van de SPARQL bevragingstaal vereist is. Probeer maar eens om een andere postcode in te vullen (bijvoorbeeld jouw eigen postcode), en klik daarna op de "Run query" knop.

Wanneer je in onderstaande klikt op "Try this query yourself" kun je inzien hoe de API variabele is geconfigureerd. (Je kunt vervolgens ook nog op de link "View populated query" klikken om te zien hoe de SPARQL engine de API variabele heeft ingevuld en gaat uitvoeren.)

BIM demo

Created 3 months ago

Waarom BIM en Kadaster Knowledge Graph?

De behoefte om gebruik te maken van gecombineerde data uit verschillende basisregisters is groot, maar momenteel moeilijk door manier waarop de basisregistraties zijn ingericht en de complexiteit van de bijbehorende gegevensmodellen. De Kadaster Knowledge Graph is een eerste oplossing voor dit vraagstuk van geïntegreerd gebruik en biedt de mogelijkheid om op een geïntegreerde manier gebruik te maken van data uit meerdere geo-basisregistraties. Deze Kadaster Knowledge Graph is generiek, dus niet gemaakt om een specifiek probleem voor een bepaalde sector op te lossen, maar biedt een oplossing voor oneindig veel vragen die leven bij verschillende gebruikers in verschillende sectoren. In deze data story kijken we naar de mogelijkheden om data uit een BIM model te bevragen in combinatie met de Kadaster Knowledge Graph.

Toekomst: naast de Kadaster Knowledge Graph zijn een of meer BIM KG’s beschikbaar, waardoor het in de toekomst mogelijk is om informatie gecombineerd te kunnen bevragen. In de toekomst wordt de BIM Knowledge Graph wellicht opgebouwd en onderhouden door diverse partijen in de bouwsector (architectenbureaus, ontwikkelaars, bouwbedrijven, installatiebedrijven), staat de informatie in die BIM KG fysiek verspreid en staat de Kadaster Knowledge Graph bij het Kadaster. Door gecombineerde bevragingen uit te voeren op zulke verschillende verspreide Knowledge Graphs maken we federatieve bevragingen mogelijk. Om de werking hiervan te laten zien hebben we onderstaande datastory opgesteld.

Voorbeeld 1: Gebouw gegevens uit de BIM model

Een voorbeeld van een querie waarin we in een bepaald gebied panden zoeken die aan bepaalde kenmerken voldoen. In dit voorbeeld zoeken we in de Wijk Hees in Nijmegen alle panden met een houten kozijn. Het pand Schependomlaan is het enige pand dat oplicht omdat dit pand houten kozijn heeft (we hebben voor deze demo maar 1 BIM model).

Idee is om met deze querie aan te tonen dat als je meerdere BIM modellen zou hebben je kan zoeken op bepaalde eigenschappen van een pand. Je krijgt dan alle panden te zien die aan de zoekcriteria voldoen.

Tutorial: SPARQL bevragingstaal

Created 3 months ago

Introductie

In dit onderdeel van de tutorial maken we je wegwijs in de SPARQL bevragingstaal. Hiermee kun je snel je eerste queries uitvoeren.

Overzicht

Deze tutorial is de derde in een reeks, bestaande uit de volgende delen:

  1. Introductie Kadaster Knowledge Graph
  2. Verken het data model
  3. SPARQL bevragingstaal ← je bent nu hier

Doel van deze module

Na deze module kun je aan je collega's uitleggen:

  • Hoe je een SPARQL bevraging kunt uitvoeren.
  • Hoe je een SPARQL bevraging kunt aanpassen.
  • Hoe je een SPARQL bevraging kunt opbouwen.

Voordat je begint

Gedurende deze module zullen we verschillende queries uitoefenen met SPARQL op de Kadaster Knowledge Graph. Om deze query te versturen gebruiken we het SPARQL API endpoint van de KKG: link. De queries die als voorbeeld op deze pagina zijn opgenomen zijn in te zien en aan te passen door op de "Try this query yourself" link te klikken.

I. Wat is SPARQL?

Sorry, your browser does not support embedded videos.
Je kunt dit deel van de tutorial ook als video bekijken.

SPARQL is de standaard taal voor het bevragen van Resource Description Framework (RDF) data. De standaard wordt beheerd door het W3C en is een onmisbaar onderdeel van Linked Data. Voor een volledige overzicht in de volledige SPARQL query language raden we de gebruiker aan die standaard dan ook eens rustig door te lezen. In deze tutorial leren we je echter de basis waarmee je je eerste selectie en combinatie vraag kan stellen aan de Kadaster datasets.

Laten we met een simpele query beginnen. We willen graag iedere triple opvragen die de waarde "Apeldoorn" als literal bevat. Omdat dit een Nederlandse string is, dienen we aan het einde van deze string een language tag mee te geven (@nl).

select ?subject ?predikaat {
  ?subject ?predikaat 'Apeldoorn'@nl.
}
limit 10

Verken het data model

Created 3 months ago

Introductie

In deze tutorial helpen we je om te kunnen exploreren door het data model van een gegeven dataset. Op deze manier kun je inzicht verkrijgen in de beschikbare data en de potentiële vragen die je met deze dataset zou kunnen exploreren.

Overzicht

Deze tutorial is de tweede in een reeks, bestaande uit de volgende delen:

  1. Introductie Kadaster Knowledge Graph
  2. Verken het data model ← je bent nu hier
  3. SPARQL bevragingstaal

Doel van deze module

Na deze module kun je aan je collega's uitleggen:

  • Hoe je het data model van een dataset kunt exploreren.
  • Hoe je de functionaliteit van een triple store gebruikt om inzichten in een dataset te krijgen.

Alle facetten van een dataset op één plek

Op de Kadaster developer pagina vindt je een overzicht van alle datasets die het Kadaster met linked data beschikbaar stelt. Daar vindt je per dataset verwijzingen conform Figuur 1.

Figuur 1. Overzicht van de Kadaster linked dataset met nuttige link voor ontwikkelaars.

Merk op dat voor iedere dataset de volgende verwijzingen zijn opgenomen:

  1. Een verwijzing naar de landing page van de dataset in de triple store. Hier vindt je metadata en changelogs voor de betreffende dataset.
  2. Een verwijzing naar het SPARQL endpoint waar een ontwikkelaar vragen over de data kan stellen.
  3. Een verwijzing naar de use cases die gebruik maken van deze dataset. Deze use cases geven een goede indruk van wat mogelijk is met de data.
  4. Een visueel overzicht van het data model van de dataset.

Voor de Kadaster Knowledge Graph lopen we door deze 4 opties heen.

Tutorial: Introductie Kadaster Knowledge Graph

Created 3 months ago

Introductie

Deze tutorial begeleidt je door het eerste gebruik van Linked Data en de Kadaster Knowledge Graph (KKG). In deze tutorial nemen we je mee in de basisvaardigheden rondom Linked Data en de SPARQL bevragingstaal. Daarna laten we zien hoe je zelf de Kadaster Knowledge Graph kunt gebruiken, en welke gereedschappen je daarbij tot jouw beschikking hebt.

In deze introductie behandelen we de volgende onderdelen:

  • Wat is Linked Data?
  • Hoe krijg je inzicht in het data model van een Linked Dataset?
  • Hoe gebruik je de bevragingstaal SPARQL?
  • Wat is de Kadaster Knowledge Graph en hoe kun je die gebruiken?
  • Hoe kun je jouw eigen gegevens combineren met gegevens uit de Kadaster Knowledge Graph?

Voorkennis

Deze tutorial gaat uit van de volgende voorkennis:

  • Je hebt vaker gewerkt met data en data modellen.
  • Je bent bekend met het bevragen van data in web-gebaseerde APIs (bijvoorbeeld REST-APIs).

Overzicht

Deze tutorial is de eerste in een reeks, bestaande uit de volgende delen:

  1. Introductie Kadaster Knowledge Graph ← je bent nu hier

  2. Verken het data model

  3. De SPARQL bevragingstaal

  4. Gebruik eigen programmeertaal

Doel van deze module

Na deze module kun je aan je collega's uitleggen:

  • Wat is Linked Data?
  • Wat is het verschil is tussen nodes, verbinden en uitspraken?
  • Wat is SPARQL?

Wat is Linked Data?

In 2006 werd de term Linked Data als eerst geopperd door Tim Berners-Lee, door velen bekend als de bedenker van het internet. De termen Linked Data en Semantisch Web zijn onlosmakelijk met elkaar verbonden. In deze tutorial zullen we voornamelijk de term Linked Data toepassen.

Linked Data heeft de volgende kernprincipes:

  • Gegevens wordt opgeslagen in een graaf structuur. Hierdoor zijn nieuwe gegevens arbitrair koppelbaar.
  • De nodes en verbinding in de graaf worden beiden aangeduid met web adressen. Dit zijn dezelfde adressen die ook gebruikt worden om pagina's op het web mee aan te duiden. Denk maar aan de adresbalk in jouw web browser waarmee je deze tutorial bezoekt.
  • Voor het persisteren van de graaf structuur wordt de RDF standaard gebruikt. Deze standaard schrijft voor dat de graaf structuur op een eenduidige manier wordt vastgelegd zodat uitwisseling met anderen mogelijk wordt.
  • Ten slotte zijn zoveel mogelijk aspecten van de Linked Data graaf vastgelegd in internationale en nationale open standaarden. Door deze standaardisatie is het mogelijk om een data graaf in Linked Data uit te wisselen met anderen.

Uitspraken

We zagen dat in Linked Data gegevens worden opgeslagen in een graaf, en dat deze graaf wordt vastgelegd volgens open standaarden.

De volgende figuur toont een simpele Linked Data graaf. Deze bevat 3 nodes ("gebouw 0200100000085932", "2006" en "Gebouw") en 2 verbindingen ("bouwjaar" en "type"). We behandelen deze 3 nodes een voor een:

  1. Node "gebouw 0200100000085932" duidt een specifiek gebouw in Nederland aan. Deze node heeft een uniek web adres en is daarom aanklikbaar in de afbeelding.
  2. Node "2006" duidt het jaartal 2006 aan. Deze node heeft geen uniek adres en is daarom niet aanklikbaar in de afbeelding.
  3. Node "Gebouw" duidt de definitie van een gebouw aan. Deze node heeft een uniek web adres en is daarom aanklikbaar in de afbeelding.

Een verbinding maakt altijd gebruik van 2 nodes. Een verbinding met 2 nodes legt een betekenisvolle uitspraak vast. De afbeelding bevat de volgende 2 uitspraken:

  1. "Dit specifieke gebouw met codering 0200100000085932 heeft als bouwjaar het jaartal 2006."
  2. "Dit specifieke gebouw met codering 0200100000085932 is een gebouw."

Omdat een uitspraak in linked data uit 3 componenten bestaat (1 verbinding tussen 2 nodes) spreken we over een 'triple'. Bovenstaande afbeelding laat 2 triples zien, maar de Kadaster Knowledge Graph bevat miljarden van dergelijke triples. Merk op dat het principe, de 'triple', op zichzelf heel eenvoudig is. Daarnaast biedt het principe van de 'triple' een grote mate van openheid: het is altijd mogelijk om een nieuwe verbinding toe te voegen wanneer meer informatie bekend wordt.

International Resource Identifiers (IRIs)

We zagen dat 2 van de 3 nodes in de bovenstaande afbeelding aanklikbaar zijn. De 2 nodes die aanklikbaar zijn maken gebruik van web adressen. Wanneer het web adres wordt opgevraagd worden de gegevens van het door dat web adres aangeduide gegeven opgehaald. Je kunt dit eenvoudig testen door op de node "gebouw 0200100000085932" te klikken. Je zult zien dat jouw web browser vervolgens de gegevens over dat specifieke gebouw gaat ophalen en toont.

Afbeelding 2. Screenshot van het opzoeken van de IRI voor een specifiek gebouw.

Het is een fundamentele eigenschap van linked data dat de naam van een data element ook de locatie op het Internet is waar de directe gegevens over dat data element kunnen worden opgehaald. In linked data kun je vaak opzoeken wat iets betekent door er op te klikken.

Merk ten slotte op dat er 1 node was die niet aanklikbaar was: het jaartal 2006. Voor tekstuele inhoud en numeric waardes wordt meestal geen gebruik gemaakt van web adressen. De technische term voor dit soort linked data termen is 'literals'.

Objecten, Attributen & Definities

In linked data wordt een onderscheid gemaakt tussen instantiegegevens en definities (soms ook 'schema' genoemd).

Instantiegegevens duiden specifieke objecten of entiteiten aan. We geven 2 voorbeeld van instanties die in de Kadaster Knowledge Graph voorkomen:

  1. De specifieke woonplaats Appingedam.
  2. De specifieke openbare ruimte met code 0003300000117021.

De definities beschrijven het data model waar de instantiegegevens aan voldoen. Er zijn twee soorten definities: eigenschappen en klassen.

Eigenschappen duiden de betekenis van verbindingen tussen nodes aan. We geven 2 voorbeelden van eigenschappen die in de Kadaster Knowledge Graph gebruikt worden:

  1. De eigenschap "bouwjaar" wordt aangeduid met de IRI sor:oorspronkelijkBouwjaar. Deze eigenschap wordt als onderdeel van de Kadaster Knowledge Graph gedefinieerd. Als je wil weten wat deze eigenschap precies inhoud kun je dit web adres bezoeken in een web browser.
  2. De eigenschap "is een" wordt aangeduid met de IRI rdf:type. Deze eigenschap maakt onderdeel van de RDF standaard uit. Dit is een voorbeeld van een bestaande eigenschap die binnen de Kadaster Knowledge Graph wordt hergebruikt. Een belangrijke functionaliteit van linked data is dat het eenvoudig is om bestaande definities van andere te hergebruiken.

Ten slotte zijn er klassen. Deze worden gebruikt om generieke kennis vast te leggen. Ieder instantiegegeven behoort to een of meerdere klassen. De klasse of klassen duiden aan wat voor soort gegeven een instantiegegeven is. In bovenstaande afbeelding duidde de node "Gebouw" een klasse aan. Deze klasse heeft IRI sor:Gebouw en legt vast wat het betekent om een gebouw te zijn conform de definitie die de Nederlandse overheid daarvoor hanteert.

Wat is SPARQL?

SPARQL is de standaard bevragingstaal waarmee een linked dataset bevraagd kan worden. Voor gebruikers met een technische achtergrond kan het helpen om te weten dat SPARQL als bevragingstaal voor linked data vergelijkbaar is met de bekende SQL bevragingstaal voor relationele database systemen. Net als met SQL is een ontwikkelaar in staat om met SPARQL ingewikkelde vragen te stellen en antwoorden te ontvangen. Het web adres waar SPARQL over de Kadaster Knowledge Graph kan worden uitgevoerd is: https://data.kkg.kadaster.nl/sparql

Afbeelding 3. Screenshot van de web pagina waar SPARQL vragen aan de Kadaster Knowledge Graph gesteld kunnen worden.

Als je naar het web adres voor SPARQL gaat kun je al meteen een aantal voorbeeld bevragingen uitvoeren door op de bijbehorende tabs te klikken. Bevragingen worden live uitgevoerd door op de 'play' knop (bovenaan rechts) te klikken.

Overzicht Basisregistratie Kadaster (BRK)

Created 3 months ago

De Kadastrale Kaart

Sinds kort is ook de Kadastrale Kaart als Linked Data beschikbaar. Momenteel kent deze nog geen verbindingen naar andere basisregistraties. Wel is er een link naar de BAG in de maak. Deze linkset wordt binnen het Kadaster al actief onderhouden en stelt ons straks in staat om alle basisregistraties als één geconnecteerd geheel te bevragen. In onderstaande query vind je een voorbeeld van een bevraging op de Kadastrale Kaart. Hiermee laten we zien hoe we vanuit een Kadastrale Gemeente alle kadastrale percelen kunnen bevragen en op de kaart kunnen tonen. Voor performance redenen is het aantal percelen in deze query gelimiteerd tot de eerste 10000.

Let op dat een Kadastrale gemeente niet noodzakelijkerwijs gelijk is aan reguliere (CBS) gemeente. Er is wel een administratieve koppeling aanwezig, maar deze is (nog) niet onderdeel van de levering.

Bomen in gemeenten

Created 3 months ago

De Basisregistratie Grootschalige Topografie (BGT) kan in verschillende situaties worden gebruikt en bevat vaak enkele plus-type data die niet voor elke gemeente verplicht zijn, maar wel interessant kunnen zijn wanneer deze worden opgenomen. Een van deze klassen van het plus-type zijn openbare boominstanties. De eerste vraag die we onszelf moeten stellen als we van plan zijn om deze plus data te gebruiken, is: 'Welke gemeenten houden een bepaald type plus data bij?'

De gemeenten (top 25 in volgorde van grootste aantal boominstanties) die boom plus-type data bijhouden zijn als volgt (Figuur 1).

Wegwerkzaamheden

Created 3 months ago

De Basisregistratie Grootschalige Topografie (BGT) kan voor verschillende use cases gebruikt worden. En voorbeeld van zo'n use case is wegonderhoud. Wanneer onderhoud aan wegen plaatsvind is er vaak de behoefte om omwonenden daarvan op de hoogte te stellen. Omdat alle wegdelen in Nederland in de BGT worden geregistreerd kan aan het begin van een onderhoudstraject een uitdraai gemaakt worden van de adressen die moeten worden aangeschreven. Dit wordt in Figuur 1 getoond.

Overzicht van de Basisregistratie Grootschalige Topografie (BGT)

Created 3 months ago

1. Inleiding

Deze data story geeft een overzicht van de BGT-LD dataset. De BGT staat voor "Basisregistratie Grootschalige Topografie", en LD staat voor "linked data". Deze linked data publicatie van de BGT stelt gebruikers in staat om de BGT op verschillende manieren te bevragen.

2. Metadata

De BGT-LD bevat een uitgebreide metadata beschrijving van de dataset en de diensten die daarover worden aangeboden. Deze metadata kunnen door applicaties worden gebruikt om de BGT-LD op verschillende manieren te kunnen visualiseren en gebruiken. Voor de metadatering wordt gebruik gemaakt van de volgende metadata standaarden: Schema.org, DCAT 2, DQV, SPARQL Service Description, VoID, Dublin Core Terms.

De volgende links laten twee voorbeelden van metadata ontsluiting zien:

3. Definities

De BGT-LD bevat definities voor ieder object type. De definities leggen de betekenis van de BGT concepten vast. Hierdoor is het voor een gebruiker van de BGT-LD mogelijk om vast te stellen wat de precieze betekenis van bepaalde termen is. In Figuur 1 wordt een voorbeeld van een definitie gegeven. Het is mogelijk om verschillende definities te selecteren en te tonen.

OpenELS

Created 3 months ago

Administrative units

Usually, the territory of a country is divided into a number of areas that are administered by local government. Such areas are called administrative units. The systems of such administrative division are hierarchical with several levels of progressively smaller units. Municipalities, regions and provinces are examples of administrative units at different levels. However, often it is difficult to compare structures of administrative division between countries because they use language-specific names for levels of administrative division.

“Sorry, what do you call that?”

Let's see what names are used to refer to the corresponding administrative levels in the Netherlands, Norway, Spain and Finland.

Try it out: You can see the exact query used to retrieve the data by clicking the blue arrow button below this box. The query is running over the 4 national sparql endpoints of the project and retrieving the different names used for the varying administrative levels. You can view the returned data in different presentation formats by clicking on the options at the bottom of the query. The data can also be downloaded in CSV format.

Evacuatie o.b.v. Kadastrale gegevens

Created 3 months ago

Inleiding

Welke huizen vallen binnen de radius van de calamiteit? En welke huizen staan er het dichtste bij? Dat zijn de eerste vragen die gesteld worden als er een calamiteit in Nederland optreed waarbij evacuatie nodig is. Om deze vragen te kunnen beantwoorden is actuele informatie essentieel. Het Kadaster ontsluit steeds meer datasets bij de bron, met behulp van linked data. Een van deze bronnen is de Basisregistratie Adressen en Gebouwen (BAG). We gebruiken een live database bevraging (SPARQL) om de actuele data op te halen.

In Figuur 1 worden de BAG panden getoond die binnen een radius van 1 kilometer rondom een als calamiteit aangemerkt punt liggen. Het label geeft het gebouwtype weer vanuit de BRT en de gebruiksfunctie vanuit de BAG. Deze functie kan van belang zijn tijdens het uitvoeren van een evacuatie.

Basisregistratie Adressen en Gebouwen (BAG) 2.0

Created 3 months ago

De Basisregistratie Adressen en Gebouwen (BAG) bevat informatie over alle adressen en gebouwen in Nederland. De data uit de BAG wordt op verschillende manieren ontsloten. Één van deze manier is Linked Data, waarmee de BAG bevraagd kan worden. Linked Data is een nieuwe manier om gegevens te representeren, combineren, en op het Internet te ontsluiten. Om Linked Data te kunnen bevragen maken wij gebruik van SPARQL. SPARQL is de gestandaardiseerde bevragingstaal voor Linked Data.

Hieronder zijn enkele voorbeelden van bevragingen over de BAG. Het mogelijk is om de bevraging aan te passen door waardes in te vullen in de invoervelden. Het is ook mogelijk om de bevraging direct aan te passen, door de ‘editor’ component te openen.

Bevraging op basis van postcode

Een veel voorkomende manier om BAG gegevens op te vragen is door een postcode en (optioneel) huisnummer op te geven (Bevraging 1). Sommige adressen hebben bovendien een huisletter en/of huisnummertoevoeging.