Deze datastory geeft voorbeeld queries die op de KKG kunnen worden uitgevoerd. Hierbij wordt data gebruikt uit de verschillende registraties zoal BAG en BGT.

Hieronder vind je een korte inleiding over het KKG model, gevolgd door zeven voorbeeld queries. Test je mee?

Gebruikers tip: Met de optie 'try this query yourself' kun je het resultaat in een andere vorm presenteren; b.v. op een kaart, in een tabel of als grafiek.

Binnen het Data-Science team van Kadaster zijn recent twee voorspelmodellen rondom bouwlagen (verdiepingen) afgerond. De eerste daarvan is het bepalen van, gegeven een verblijfsobject (vbo) zoals een appartement, de verdieping van het pand waarop dit vbo zich bevindt. Deze informatie kan bijvoorbeeld belangrijk zijn voor de tijdsplanning van pakketbezorgers, of om een indicatie te geven van welke vbo's droog blijven bij een overstroming. Het tweede model heeft als doel om het aantal verdiepingen van een gegeven pand te voorspellen. Dit kan onder andere interessant zijn voor de bepaling van energiegebruik, of het voorspellen van renovatiekosten.

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.

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.

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.

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.

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.

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.

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)

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.)