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.

DISCLAIMER: The data used to demonstrate a building permit application is entirely fake. No personally identifiable information is available in these datasets.

DISCLAIMER: The data used to demonstrate a real estate transaction is entirely fake. No personally identifiable information is available in these datasets.

Het volgende gebruikersverhaal is een eerste poging om de implementatie van de autorisatie-ontologie te demonstreren die is ontwikkeld als onderdeel van het Lock-Unlock-project. De autorisatie-ontologie bestaat in de praktijk uit twee delen. De eerste is de authenticatie van gebruikers en de tweede is de autorisatie van gebruikers voor een bepaald doel.

In de praktijk zou de authenticatie van gebruikers en gebruikersinformatie afzonderlijk worden opgeslagen van de autorisatie-informatie die op een bepaalde rol wordt toegepast. Deze indeling is ook hier doorgevoerd.

De authenticatiedataset vindt u hier en de autorisatiedataset vindt u hier. De schema's voor beide datasets zijn te vinden onder het tabblad 'insights'.

In deze story zijn queries te vinden die niet zonder meer gevraagd mogen worden. Het betreft hier dus queries die vragen naar gesloten delen van de dataset. De queries worden gewoon uitgevoerd omdat de data nog niet afgeschermd is. Het betreft hier fictieve data.

Alle predicaten in deze dataset

Via Spex kunnen we op basis van de gegevens een model afleiden. SpexModel

Met Spex kan een datamodel gemaakt worden op basis van de aanwezige gegevens. NHR

Hieronder alle predicaten in deze dataset

Het is mogelijk om een schema te extraheren op basis van de aanwezige data. Spex is een tool die dit kan. Hieronder een link voor het schema op basis van de data volgens Spex. schema

Hieronder alle predicaten in deze dataset.

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.

Lock Unlock

Inleiding

De kabels en leidingen dataset is geconverteerd vanuit een geopackage file en naar linked data vertaald. Deze dataset is vervolgens aanwezig in deze omgeving op een zogenaamde triplestore, een database voor linked data. Toegang tot deze database kan plaatsvinden via een zogenaamd sparql endpoint: Een rest api waar een query volgens het sparql formaat naar toe gestuurd kan worden. Deze datastory werkt ook op basis van deze techniek. Grafieken, tabellen en kaartjes zijn geproduceerd op basis van sparql queries op de dataaset.

Deze datastory laat zien wat er zoal te vinden is in deze Kabels en leidingen linked dataset.

De eerste figuur laat een klein stukje data zien. In deze figuur is te zien dat de data direct gekoppeld is aan een klasse. Oftewel data is direct gekoppeld aan het schema. Daarnaast is te zien dat data elementen direct verbonden zijn met andere data elementen. In dit geval zijn Kabels en leidingen direct verbonden met punt objecten en bijbehorende schema objecten.

Tijdens het project Semantische Samnehang tussen Basisregistraties is het IMX Geo-model ontwikkeld. Dit model is gebruikt bij de ontwikkeling van de IMX-Geo Knowledge Graph. Een compleet overzicht van het model als ontologie is hier beschikbaar: https://data.labs.kadaster.nl/staging-imx-geo/imx-geo/schema

Het volgende data story geeft een eerste inzicht in de inhoud van de IMX-Geo Knowledge Graph, inclusief enkele voorbeelden van gebruikersvragen die kunnen worden beantwoord met behulp van de Graph.

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.

visualisatie van ruimtelijke plannen op basis van de zeewolde dataset

The following data story is defined in order to support the documentation of the development of the Kadaster Knowledge Graph (KKG) based on the IMX-Geo ontology. The ontology is published here and is visualised here. The following sections both highlight the content of the IMX-Geo KKG to date and as well as the relevant steps taken in its development.

Download optie voor de BGT: link

Introductie

De voortgang van de energietransitie moeten we kunnen volgen. We willen weten of we op de goede weg zijn bij het behalen van onze doelstellingen, dus b.v. of er voldoende windmolens zijn geplaatst en gepland. Daarnaast willen we weten waar ze staan, om b.v. te kunnen inschatten of ze goed ruimtelijk zijn ingepast, of ze een veiligheidsrisico vormen. Na een kort zoekrondje op internet binnen de publieke sites, blijkt het lastig om een eenduidig antwoord te vinden op b.v. de relatief makkelijke vraag hoeveel windmolens er per provincie zijn.

Vanuit VIVET hebben we onderzocht of het stelsel van basisregistraties een eenduidig antwoord zou opleveren. We hebben juist in de basisregistraties gezocht, omdat het proces van actualisatie door o.a. gemeenten, wettelijk is geregeld en overheden de basisregistraties verplicht moeten gebruiken. We zien dat de verschillen in aantallen windmolens op de publieke sites. De verschillen lijken grotendeels te verklaren door het verschil in moment-opname en de definities gehanteerd binnen het inwinningproces.

De keuze voor het verzamelen van gekoppelde informatie aan de basisregistraties is het faciliteren van zowel actualiteit alsook flexibiliteit. Hierbij willen we niet steeds losse koppelingen maken met gedownloade databestanden, waarmee niet beide randvoorwaarden optimaal worden gefaciliteerd. Door te werken met dynamische koppelingen in een gekoppeld (federatief) stelsel, houden we meer actualiteit in het overzicht en flexibiliteit in het type gewenste vragen/informatie. We hebben daarom gekeken naar het opstellen van een Knowledge Graph van de basisregistraties, die we ook gekoppeld hebben aan data van andere overheden, zoals b.v. atlas van de leefomgeving van RIVM en RVO over de SDE-subsidie.

Opmerking: we presenteren op deze pagina de resultaten uit twee focusdagen waarin gegevens van de BGT, BRT, RIVM en Topstakels werden gecombineerd en geanalyseerd. Het resultaat staat in de #Energie Knowledge Graph. De herkomst van de data zal in verdere iteraties worden toegevoegd aan de grafiek, zodat ook de originele gegevens kunnen worden getraceerd. Door deze actieve koppeling naar de originele gegevens, houden we het #Energie Knowledge Graph met minimale inspanning actueel. Ook kunnen we makkelijk koppelingen naar andere open-data sources koppelingen maken, zoals b.v. het SDE subsidie bestand van RVO.

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.

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.

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.

• Datumtype van de bron
• Status
• Jurische toegangsrestricties
• Gebruiksbeperkingen

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.

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.

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.

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.