Logboek voor BGT Ontwikkeling

Introductie

In dit logboek wordt de ontwikkeling van de linked data versie van de Basisregistratie Grootschalige Topografie (BGT) bijgehouden.

De huidige staat van de BGT dataset kan hier gevonden worden.

BGT klasse hierarchie onder NEN 3610

0. TODO

0.1 Losse vragen/opmerkingen

  • Wat betekent "niet-bgt" ("Het object is geen BGT object. (bron: BGT 1.1)") als waarde voor FunctieSpoor in de BGT Gegevenscatalogus.
  • De bron voor ‘FysiekVoorkomen onverhard’ is “BGT” op één plek en “IMGeo” op een andere plek in de BGT Gegevenscatalogus.
  • ImGeo wordt soms geschreven als “IMGEO” in de BGT Gegevenscatalogus.
  • ‘Duin’ heeft een lege bron in de BGT Gegevenscatalogus.
  • Hoe om te gaan met onzekerheid? Dit wordt in de BGT soms aangeduid met transitie (bijvoorbeeld voor 'inwinningsmethode', 'functie' en 'fysiek voorkomen'), maar dit komt niet voor in de BGT Gegevenscatalogus.
  • Tussenliggende concepten hebben meestal nog geen definitie in de BGT Gegevenscatalogus (bijvoorbeeld 'bouwwerk').
  • Een aantal inwinningsmethodes komt wel voor in de BGT, maar niet in de BGT Gegevenscatalogus (bijvoorbeeld 'scannen').
  • In de BGT Gegevenscatalogus staat "Toelichting attribuut: Zie 3.10 van de gegevenscatalogus." Dit zou mogelijk sectie 3.9 moeten zijn.
  • Wat is de relatie tot INSPIRE? Bijvoorbeeld "Toelichting objecttype: Deze klasse komt overeen met OtherConstruction in het Inspire Buildings thema." uit de Gegevenscatalogus.
  • De objecttypes die als "niet-bgt" worden aangemerkt hebben geen beschrijving of definitie in de IMGeo Gegevenscatalogus (bijv. 'keermuur', 'overkluizing', 'duiker', 'faunavoorziening', 'vispassage', 'bodemval', 'coupure', 'ponton', 'voorde').
  • Zand komt twee keer voor in de fysiek voorkomen concept collectie: bgt:zand en bgt:zandPlus.

0.2 Spatial Data on the Web Best Practices:

  • Best Practice 1: Use globally unique persistent HTTP URIs for Spatial Things
  • Best Practice 2: Make your spatial data indexable by search engines
  • Best Practice 3: Link resources together to create the Web of data
  • Best Practice 4: Use spatial data encodings that match your target audience
  • Best Practice 5: Provide geometries on the Web in a usable way
  • Best Practice 6: Provide geometries at the right level of accuracy, precision, and size
  • Best Practice 7: Choose coordinate reference systems to suit your user's applications
  • Best Practice 8: State how coordinate values are encoded
  • Best Practice 9: Describe relative positioning
  • Best Practice 10: Use appropriate relation types to link Spatial Things
  • Best Practice 11: Provide information on the changing nature of spatial things
  • Best Practice 12: Expose spatial data through 'convenience APIs'
  • Best Practice 13: Include spatial metadata in dataset metadata
  • Best Practice 14: Describe the positional accuracy of spatial data

1. Metadata

We kunnen deze metadata beschrijving voor de BGT ontlenen aan het Nationaal Georegister (NGR).

2. IRI strategie

In de IRI strategie BGT wordt vastgelegd hoe namen voor objecten in de linked data versie van de BGT zullen worden uitgegeven. Hierbij volgen we grotendeels de Aanzet tot een nationale URI-Strategie voor Linked Data van de Nederlandse overheid (hierna 'Aanzet') en de manier waarop het Kadaster Data Platform (KDP) op dit moment IRIs uitgeeft.

Op sommige punten zullen wij echter afwijken van de Aanzet en/of van de KDP aanpak. We zullen dit doen op onderdelen waar de Aanzet en de KDP methode achterhaald zijn, en op onderdelen waar het letterlijk volgen van de Aanzet en de KDP methode tot nodeloze complexiteit zou leiden.

In lijn met de Aanzet en de KDP aanpak kan een linked data IRI worden opgedeeld in de volgende componenten:

{schema}://{domein}/{type}/{subtype}/{referentie}

We zullen elk van deze componenten kort behandelen in een eigen subsectie. Ten slotte zullen we een aantal voorbeelden geven van BGT IRIs die volgens deze strategie zijn aangemaakt.

2.1 {schema}

Voor de linked data BGT gebruiken we het https schema. In de Aanzet en in KDP wordt het http schema gebruikt. Het verschil tussen deze twee schema's is dat HTTP IRIs geen gebruiken maken van het beveiligingsprotocol SSL, terwijl HTTPS IRIs hier wel gebruik van maken. Het gebruik van het beveiligingsprotocol SSL is de laatste jaren gemeengoed geworden op het Internet. Moderne web browsers laten waarschuwingen zien wanneer een niet-SSL HTTP IRI wordt ingevoerd. Het gebruik van een niet-SSL HTTP IRI binnen een beveiligde applicatie of web pagina wordt eveneens door moderne web browsers aangeduid met een waarschuwing. Ten slotte worden niet-SSL HTTP IRIs lager getoond in zoekresultaten in moderne web zoekmachines. De kans bestaat dat het gebruik van niet-SSL HTTP IRIs op termijn verder ontmoedigd zal worden, en ― binnen sommige omgevingen ― zelfs geheel zal worden geweerd.

Het is technisch mogelijk om zowel niet-SSL HTTP IRIs alsook HTTPS IRIs gelijktijdig te ondersteunen. Hierbij resulteert het bevragen van een niet-SSL HTTP IRI in een doorverwijzing ('redirect') naar de corresponderende HTTPS IRI. Deze oplossing is technisch in te richten, maar heeft de volgende nadelen:

  • Verwarring bij gebruikers Er komen 2 IRIs in omloop die allebei hetzelfde BGT object identificeren. Sommige gebruikers zullen de HTTP IRI gaan gebruiken en anderen zullen de HTTPS IRI, mogelijk ook door elkaar heen, gaan gebruiken. Dit kan voor verwarring bij de gebruiker leiden. De vraag "Welke IRI moet ik gebruiken?" zal frequent en helder beantwoord moeten worden.

  • Hogere onderhoudskosten Het gebruik van 2 IRIs voor hetzelfde object betekent dat in BGT bevragingen en in BGT applicaties rekening moet worden gehouden met het mogelijke gebruik van 2 soorten IRIs. Bijvoorbeeld een software onderdeel dat op basis van een BGT object identificatie een ander gegeven teruggeeft moet zowel de HTTP IRI alsook de HTTPS IRI kunnen accepteren en verwerken. Per individuele bevraging is dit een relatief kleine investering, echter keert deze investering op veel plekken terug. Daarnaast moeten ontwikkelaars zich blijvend bewust zijn van het mogelijke gebruik van 2 soorten IRIs. Over de tijd heen moet daarom rekening gehouden worden met hogere beheerskosten wanneer voor het gebruik van 2 IRIs gekozen wordt.

  • Hogere server belasting Wanneer een HTTP IRI bevraagt wordt moet de server doorverwijzen naar de corresponderende HTTPS IRI. Dit betekent dat gebruikers twee bevragingen in plaats van één bevraging moeten uitvoeren. Daarnaast moet de server twee bevragingen in plaats van één bevraging afhandelen. Merk op dat deze extra server belasting in de praktijk zal meevallen, en mogelijk slechts enkele procent extra performance zal kosten. Tegelijkertijd is het niet ondersteunen van HTTP IRIs een eenvoudige manier om een kleine besparing op toekomstige server capaciteit te realiseren.

2.2 {domein}

Voor het domein volgen we de manier waarop de bestaande linked data basisregistraties door KDP worden ontsloten. Hierbij wordt tevens de Aanpak gevolgd, waarin wordt gewaarschuwd voor het gebruik van een organisatienaam als onderdeel van het domain. (Organisatienamen veranderen namelijk regelmatig.) Dit betekent dat het volgende domein voor de linked data BGT wordt gebruikt:

bgt.basisregistraties.overheid.nl

Dat is in lijn met de volgende bestaande IRI prefixen die door KDP worden aangeboden:

bag.basisregistraties.overheid.nl
brt.basisregistraties.overheid.nl

2.3 {type}

We stellen voor om de volgende types te gebruiken:

  • def/ voor definities; dat wil zeggen BGT klassen en BGT eigenschappen.

  • id/ voor instanties; dat wil zeggen individuele BGT objecten.

In de Aanzet wordt naast def/ en id/ type, ook het gebruik van het doc/ type voorgesteld. Het gebruik van het doc/ type hangt samen met een onderscheiding die traditioneel in linked data gemaakt wordt tussen een object (aangeduid met type id/) en een pagina over dat object (aangeduid met type doc/). Het idee is dat op het moment dat de id/ IRI in een web browser gebruikt wordt een doorverwijzing gevolgd wordt naar de corresponderende doc/ IRI. Merk op dat voor def/ IRIs een dergelijke doorverwijzing niet wordt voorgesteld, alhoewel het onderscheid tussen een concept en een pagina over dat concept theoretisch gezien ook gemaakt zou kunnen worden.

Voor de linked data BGT wordt geen gebruik gemaakt van deze traditionele doorverwijzingspraktijk, omdat het gebruik van id/ en doc/ in de praktijk de volgende problemen veroorzaakt:

  • Verwarring bij de gebruiker Wanneer gebruik gemaakt wordt van een id/ IRI, wordt deze binnen de web browser automatisch vervangen door de corresponderende doc/ IRI. Dit betekent dat de gebruiker niet zomaar de URL in de web browser kan gebruiken om het opgezochte object mee te identificeren. Een gebruiker moet zich er van bewust zijn dat er een onderscheid wordt gemaakt tussen een object (type id/) en een pagina over dat object in de web browser (type doc/). Omdat dit onderscheid nergens anders op het web gemaakt wordt kan dit tot verwarring leiden bij de gebruiker.

  • Trager gebruik Wanneer wordt doorverwezen van id/ naar doc/ IRIs duurt een bevraging van een IRI in de web browser langer dan wanneer de id/ IRI direct toegang verschaft tot het opgevraagde web document. Dit is een relatief kleine vertraging van enkele tientallen procenten. Echter, het niet implementeren van de doc/ doorverwijzing is een eenvoudige manier om alle bevragingen van IRIs een klein beetje sneller te maken.

  • Hogere onderhoudskosten Wanneer wordt doorverwezen van id/ naar doc/ IRIs moet extra code onderhouden worden: er moet immers een doorverwijzing worden onderhouden van de ene naar de andere IRI. De doorverwijzingen in sectie 2.1, van HTTP naar HTTPS IRIs, is een standaard operatie die door bestaande software componenten ondersteund wordt. Dat is niet het geval voor de doorverwijzing van id/ naar doc/ IRIs. Deze laatste vereist in veel gevallen code die geschreven en onderhouden moet worden.

  • Hogere server belasting Evenals bij de doorverwijzing van HTTP naar HTTPS IRI (sectie 2.1), resulteren doorverwijzingen van id/ naar doc/ IRIs tot een verdubbeling van het aantal bevragingen dat door de server moet worden afgehandeld. Ook dit is weer een performance penalty van ten minste enkele procenten.

2.4 {subtype}

Het subtype wordt eveneens gebruikt in combinatie met het id/ type om het soort instantie weer te gegeven. Bijvoorbeeld, voor een pand wordt het subtype pand/ gebruikt, waardoor het pand met /id/pand/ begint. Hierin volgt de linked data BGT de Aanzet en de KDP methode.

Omdat het aantal instanties in de BGT er groot is (vele miljoenen) en de referentie vaak betekenisloos is (een arbitraire code), biedt het subtype enige houvast voor het soort van instantie waar we mee te maken hebben. De subtypes zorgen ervoor dat de grote ruimte van instantie IRIs wordt opgedeeld in betekenisvolle categorieën.

Hierbij is het wel van belang dat iedere id/ IRI precies één subtype heeft, die bovendien eenvoudig vast te stellen is. Voor de BGT garanderen we dat voor iedere instantie IRI één directe hoofdklasse wordt toegekend. Bijvoorbeeld, ieder pand is een instantie van klasse bgt:Pand, ieder onbegroeid terreindeel is een instantie van klasse bgt:OnbegroeidTerreindeel, etc. Het {subtype} wordt vervolgens gevormd door de referentie van de klasse te nemen, met een kleine beginletter. Bijvoorbeeld /id/pand/ voor instanties van klasse bgt:Pand, en /id/onbegroeidTerreindeel/ voor instanties van klasse bgt:OnbegroeidTerreindeel.

Voor het def/ type wordt geen subtype gebruikt. De belangrijkste redenen hiervoor zijn dat (1) er veel minder definitie IRIs zijn (enkele tientallen), en (2) de referentie namen voor definitie IRIs vaak al betekenisvol zijn (bijvoorbeeld bgt:Pand of bgt:bestaand).

2.5 {referentie}

Voor definities wordt gebruik gemaakt van een betekenisvolle naam als referentie. Deze naam moet aan bepaalde syntactische eisen voldoen waardoor deze binnen een IRI gebruikt kan worden. De referentie naam voor een begroeid terreindeel is bijvoorbeeld BegroeidTerreindeel aan elkaar geschreven, omdat spaties in IRIs niet zijn toegestaan.

Daarnaast wordt de referentie voor een eigenschap traditioneel met een kleine letter geschreven, terwijl de referentie voor een klasse traditioneel met een grote letter geschreven wordt. Deze conventie is nuttig omdat er soms een eigenschap is die dezelfde naam heeft als de klasse waar deze eigenschap naar verwijst. Bijvoorbeeld, het NEN 3610 vocabulaire bevat klasse nen3610:Identificatie en een eigenschap nen3610:identificatie.

Voorbeelden van referenties voor definitie IRIs in de BGT zijn Wegdeel voor een klasse, en relatieveHoogteligging voor een eigenschap.

Voor instanties wordt gebruik gemaakt van een betekenisloze identificatiecode. Dit wordt specifiek voor instanties gedaan omdat deze vaak geen betekenisvolle naam hebben. In de context van de BGT is het bijvoorbeeld niet aannemelijk dat ieder begroeid terreindeel of ieder individueel pand een betekenisvolle naam heeft. Om deze instantie IRIs toch nog enigszins te kunnen duiden worden betekenisvolle subtypes gebruikt (zie sectie 2.4).

2.6 Scheidingsteken

Tussen elke twee linked data IRI componenten komt een scheidingsteken voor:

  • Het scheidingsteken tussen het {schema} en het {domein} is de drie-karakter sequentie ://.
  • Het scheidingsteken tussen de andere componenten is de voorwaartse slash (/).

In de Aanzet wordt een alternatieve aanpak beschreven voor het laatste scheidingsteken: het teken dat direct voor de {referentie} staat. Hiervoor kan in plaats van een voorwaartse slash (/) namelijk een hekje (#) gebruikt worden. Dit alternatieve scheidingsteken kan uitsluitend gebruikt worden voor IRIs die definities aangeven (de def/ IRIs). In de KDP aanpak wordt voor definities gebruik gemaakt van dit alternatieve scheidingsteken.

Het verschil tussen een / en een # teken heeft een belangrijke functionele consequentie:

  • Wanneer het laatste scheidingsteken een voorwaartse slash (/) is, wordt elke individuele IRI apart opgevraagd. Wanneer een klasse of een eigenschap wordt op gevraagd wordt alleen die ene klasse of die ene eigenschap door de server teruggegeven.
  • Wanneer het laatste scheidingsteken een hekje (#) is, wordt alle data in één keer opgevraagd. Dit is ook de reden waarom het hekje alleen wordt voorgesteld voor definitie IRIs, omdat het aantal definitie IRIs voor veel datasets klein is (in tegenstelling tot het aantal instantie IRIs). Wanneer een klasse of een eigenschap wordt opgevraagd worden alle klassen en alle eigenschappen teruggegeven.

Voor de linked data BGT wordt als laatste scheidingsteken de voorwaartse slash (/) gebruikt, om de volgende redenen:

  • Verwarring bij de gebruiker Bij het bevragen van een instantie IRI is de gebruiker gewend om de beschrijving van die ene specifieke instantie terug te krijgen. Wanneer een gebruiker een definitie IRI bevraagt krijgt deze ineens meerdere definities terug. Dit kan verwarrend zijn voor gebruikers die niet bekend zijn met linked data. Daarnaast kan het voor de gebruiker enige moeite kosten om uit de totaliteit van teruggegeven definities de ene definitie op te halen die ook daadwerkelijk bevraagd is. Wanneer de gebruiker goede linked data libraries gebruikt om de gegevens te verwerken is deze extra moeite echter relatief beperkt, omdat goede linked data libraries ondersteuning bieden voor het uitfilteren van de opgevraagde informatie.

  • Trager in het gebruik Wanneer alle definities worden doorverwezen wanneer één definitie wordt opgevraagd betekent dit dat er meer gegevens moeten worden verstuurd. Hierbij speelt mee dat het model van de BGT ― zeker met inachtneming van de IMGeo uitbreiding ― omvangrijker is dan de meeste modellen die door het KDP worden ontsloten. Dit betekent dat bij gebruikmaking van een hash (#), voor elke bevraging van 1 definitie IRI de teruggegeven hoeveelheid 100 tot 1,000 keer groter zal zijn dan met de voorwaartse slash (/) methode. Wanneer de gebruiker over een minder snelle Internet verbinding beschikt kan deze vermenigvuldiging van de teruggegeven gegevensgrootte voor de gebruiker merkbaar trager zijn. Bij een snellere Internet verbinding zal het verschil minder of geheel niet merkbaar zijn. Tegelijkertijd is de keuze voor de voorwaartse slash aanpak een eenvoudige manier om het benodigde gegevensverkeer te verkleinen.

2.7 Conclusie

Op basis van de overwegingen in de voorgaande subsecties komen we tot de volgende IRI strategie voor de linked data BGT:

https://bgt.basisregistraties.overheid.nl/def/{eigenschap}
https://bgt.basisregistraties.overheid.nl/def/{Klasse}
https://bgt.basisregistraties.overheid.nl/id/{subtype}/{referentie}

Aan de hand van bovenstaande IRI templates kunnen concrete IRIs er als volgt uit komen te zien:

  • De mogelijke IRI voor de BGT klasse die wegdelen aanduidt: https://bgt.basisregistraties.overheid.nl/def/Wegdeel
  • De mogelijke IRI voor de BGT eigenschap die de relatieve hoogteligging van geospatiële objecten aanduidt: https://bgt.basisregistraties.overheid.nl/def/relatieveHoogteligging
  • De mogelijke IRI voor een specifiek BGT wegdeel (instantie): https://bgt.basisregistraties.overheid.nl/id/wegdeel/{referentie}

Samenvatting van veranderingen in de BGT aanpak

Zoals in de voorgaande subsecties besproken wijkt de IRI strategie voor de linked data BGT op de volgende punten af van de Aanzet en de KDP aanpak:

  • De BGT maakt gebruik van HTTPS IRIs.
  • De BGT verwijst niet door van id/ IRIs naar doc/ IRIs.
  • De BGT gebruikt de voorwaartse slash (/`) als laatste scheidingsteken.

Menselijk gebruik en machine gebruik

Voor al deze IRIs zal content negotiation ondersteund worden. Dit betekent dat voor menselijk gebruik een HTML pagina met menselijk leesbare inhoud zal worden getoond. Deze HTML pagina wordt automatisch geserveerd door web browsers, die op de achtergrond om content van het Media Type text/html vragen. Voor machine gebruik zal een RDF bestand worden uitgegeven. Dit machine formaat kan worden opgevraagd door een ander Media Type op te geven. Bijvoorbeeld application/n-triples geeft de beschrijving van de bevraagde IRI in het N-Triples formaat terug.

3. Data model

3.1 Design requirements

  • Het combineren van een informatiemodel en een kennismodel.
  • Zo veel mogelijk hergebruik van bestaande vocabulaires (zo min mogelijk eigen klassen en eigenschappen definiëren, om zo de kosten voor het onderhoud te minimaliseren).
  • Implementatie van relevante standaarden en best practices.
  • Gericht op de linked data gebruiker, maar ook gericht op data gebruikers in het algemeen (d.w.z. zonder voorkennis van linked data).
  • Metadata goed beschreven, inclusief data kwaliteit (moet bijv. vindbaar zijn in zoekmachines).
  • Dereferenceable in andere applicaties (bijv. VocBench).

3.2 Kennismodel en informatie model

Als we naar de BGT Gegevenscatalogus kijken zien we dat daarin twee soorten objecttypen en attribuutwaardes beschreven worden:

  1. Objecttypes (en attribuutwaardes) die geen opzichzelfstaande betekenis hebben, maar die noodzakelijk zijn om de BGT gegevenscatalogus goed te structureren. Denk hierbij aan het objecttype 'IMGeo-object', wat dient om eigenschappen die op meerdere BGT objecttypes van toepassing zijn op een generieke manier te kunnen specificeren.
  2. Objecttypes (en attribuutwaardes) die een opzichzelfstaande betekenis hebben. Denk hierbij aan objecttypes zoals 'pand' en attribuut waardes zoals 'erf' die betekenisvolle categorieën in de werkelijkheid aanduiden. Denk hierbij ook aan concepten die betekenisvolle procedures en methodes beschrijven, zoals 'inwinningsmethode'.

Het doel van de linked data versie van de BGT is om zowel de BGT-interne processen te kunnen ondersteunen, alsook om het externe gebruik van BGT gegevens te vergemakkelijken. Voor dat eerste doel, het ondersteunen van BGT-interne processen, is het noodzakelijk dat alle aspecten die in BGT gegevenscatalogus voorkomen ook op te nemen in de linked data versie van de BGT. Echter, niet al deze aspecten zijn ook noodzakelijk voor het externe gebruik van BGT gegevens. Zo heeft een 'IMGeo-object' buiten de context van de BGT geen betekenis.

In de linked data versie van de BGT is dit bovenstaande onderscheid tussen opzichzelfstaande betekenissen en niet-opzichzelfstaande betekenissen op een systematische manier ondersteund. Dit is gerealiseerd door een onderscheid te makken tussen het BGT linked data informatie model (zie 1) en het BGT linked data kennismodel (zie 2):

  1. Informatiemodel Alle informatie die nodig is voor de BGT-interne processen is volledig behouden in het BGT linked data informatie model. Dit informatie model is vastgelegd in de SHACL specificatietaal. Het informatie model verwijst bovendien naar bestaande concepten (waar mogelijk) of naar concepten uit het BGT semantische model (waar nodig).

  2. Kennismodel Alle betekenisvolle gegevens die in de BGT zijn vastgelegd worden ontsloten in het BGT linked data kennismodel. Dit kennismodel bevat enkel concepten die binnen én buiten de BGT betekenisvol zijn. Denk hierbij aan concepten zoals 'pand', 'erf', en 'inwinningsmethode'. Het kennismodel wordt soms aangeduid met de term 'semantisch model', omdat het de kennis in een bepaald domein op basis van betekenisvolle / semantische definities vastlegt. Het BGT linked data kennismodel is vastgelegd in RDFS en OWL.

Het informatiemodel maakt hergebruik van het kennismodel: zo kan het informatiemodel aan de hand van een SHACL specificatie additionele beperkingen leggen op een semantische definitie uit het kennismodel. Op deze manier kan een concept zowel generiek ontsloten worden (RDFS+OWL definitie) alsook voor interne processen worden ingezet (RDFS+OWL+SHACL).

3.3 Gecontroleerd hergebruik

In Sectie 3.2 hebben we het onderscheid gemaakt tussen het kennismodel en het informatiemodel. Vervolgens is het van belang dat het kennismodel zo klein mogelijk is. In linked data is het namelijk de bedoeling dat we zo veel mogelijk hergebruik maken van bestaande semantische concepten. Het informatiemodel daarentegen mag meer uitgebreid zijn. Dit is een minder groot probleem, omdat definities in het informatiemodel lokaal mogelijk ten opzichte van de data bron. Vergeleken met het informatiemodel is het inherent lastiger om definities in het kennismodel op te stellen en te onderhouden. Definities in het kennismodel moeten namelijk universele geldigheid hebben, dat willen zeggen binnen en buiten de data bron.

Neem bijvoorbeeld het semantische concept van een ruimtelijk object. We zouden dit concept in het BGT kennismodel kunnen vastleggen. Echter, we moeten dan goed gaan nadenken over de juiste definitie van wat een ruimtelijk object nu eigenlijk is. Dat is helemaal niet verstandig, want daarmee zou iedere Kadastrale dataset zijn eigen definitie van een ruimtelijk object gaan vastleggen. Het is natuurlijk veel slimmer om hergebruik te maken van een bestaande definitie. Deze bestaande definitie wordt gevonden in de linked data klasse geo:SpatialObject die is vastgelegd door de Open Geospatial Consortium (OGC).

TODO vergemakkelijkt het hergebruik van bestaande vocabulaires. Voor hergebruik is het namelijk vereist dat de semantische betekenis van de hergebruikte klassen en eigenschappen toepasbaar is. Het informatiemodel maakt het mogelijk om lokaal relevante beperkingen toe te passen op deze hergebruikte betekenissen (zolang deze de betekenis niet aanpassen).

3.4 Klasse hiërarchie

Deze sectie gaat over de klasse hiërarchie voor de BGT. Subsecties 3.4.1, 3.4.2 en 3.4.3 tonen drie verschillende klasse hiërarchieën die op dit moment gebruikt worden. Het is nog niet helemaal duidelijk goede deze verschillende hiërarchieën het beste kunnen samen komen in een consistente linked data hiërarchie.

3.4.1 BGT / CityGML hiërarchie

Dit is de BGT hiërarchie volgens onderstaande figuur, afkomstig uit de BGT Gegevenscatalogus, worden objecttypen uit de CityGML standaard als uitgangspunt genomen.

De klasse hiërarchie ziet er dan als volgt uit:

  • Core::_CityObject
    • Bridge::BridgeConstructionElement
      • Overbruggingsdeel
    • Core::_Site
      • Building::_AbstractBuilding
        • Building::BuildingPart
          • Pand
      • OverigeConstructie
        • Kunstwerkdeel
        • OverigBouwwerk
        • Scheiding
      • Tunnel::_AbstractTunnel
        • Tunnel::TunnelPart
          • Tunneldeel
    • IMGeo-Object
      • OpenbareRuimteLabel
    • Transportation::_TransportationObject
      • Transportation::AuxiliaryTrafficArea
        • OndersteunendWegdeel
      • Transportation::TrafficArea
        • Wegdeel
      • Transportation::TransportationComplex
        • Transportation::Railway
          • Spoor
    • LandUse::LandUse
      • FunctioneelGebied
      • OnbegroeidTerreindeel
    • Vegetation::_VegetationObject
      • Vegetation::PlantCover
        • BegroeidTerreindeel
    • WaterBody::_WaterObject
      • WaterBody::WaterBody
        • OndersteunendWaterdeel
        • Waterdeel
  • Plaatsbepalingspunt

Opmerkingen over bovenstaande hiërarchie:

  1. De meeste BGT concepten zitten niet onder maar naast het IMGeo-Object concept.
  2. Het BGT concept "Plaatsbepalingspunt" zit helemaal los van de rest van de hiërarchie

3.4.2 BGT / NEN 3610? hiërarchie

In de BGT Gegevenscatalogus treffen we teven het onderstaande plaatje aan, waarin een extra tussenlaag van concepten optreed. Deze extra tussenlaag staat niet in de BGT Gegevenscatalogus zelf beschreven en komt ook niet in CityGML voor; mogelijk zijn dit klassen die in een externe standaard (NEN 3610?) voorkomen.

Volgens dit plaatje ziet de hiërarchie er als volgt uit:

  • BGT-objecten
    • Bouwwerk
      • Kunstwerk
        • Kunstwerkdeel
        • Overbruggingsdeel
        • Tunneldeel
      • Overig Bouwwerk
      • Pand
      • Scheiding
    • Brondocument
      • Plaatsbepalingspunt
    • Functioneel Gebied
    • Transport
      • Ondersteunend Wegdeel
      • Spoor
      • Wegdeel
    • Terrein
      • Begroeid Terreindeel
      • Onbegroeid Terreindeel
    • Water
      • Ondersteunend Waterdeel
      • Waterdeel

Opmerkingen over bovenstaande hiërarchie:

  1. Alleen voor "BGT-objecten" wordt de meervoudsvorm gebruikt.
  2. Sommige concepten komen niet in 3.4.2 voor, bijvoorbeeld "Bouwwerk", "Kunstwerk".
  3. Plaatsbepalingspunten zijn in deze hiërarchie brondocumenten.

3.4.3 IMGeo / NEN 3610

Dit is de klasse hiërarchie volgens het Geonovum linked data model van IMGeo. Hierbij worden klassen uit NEN 3610 hergebruikt:

  • geo:SpatialObject
    • geo:Feature
      • nen3610:GeoObject
        • imgeo:IMGeoObject
          • imgeo:BegroeidTerreindeel
          • imgeo:FunctioneelGebied
          • imgeo:Inrichtingselement
          • imgeo:Kunstwerkdeel
          • imgeo:OnbegroeidTerreindeel
          • imgeo:OndersteunendWaterdeel
          • imgeo:OndersteunendWegdeel
          • imgeo:Overbruggingsdeel
          • imgeo:OverigeConstructie
          • imgeo:Pand
          • imgeo:RegistratiefGebied
          • imgeo:Spoor
          • imgeo:Tunneldeel
          • imgeo:Vegetatieobject
          • imgeo:Waterdeel
          • imgeo:Wegdeel
        • nen3610:FunctioneelGebied
          • imgeo:FunctioneelGebied
        • nen3610:Gebouw
          • imgeo:Pand
        • nen3610:GeografischGebied
        • nen3610:Identificatie
          • imgeo:NEN3610ID
        • nen3610:Inrichtingselement
          • imgeo:Inrichtingselement
        • nen3610:Kunstwerk
          • imgeo:Kunstwerkdeel
        • nen3610:Leiding
        • nen3610:PlanologischGebied
        • nen3610:RegistratiefGebied
          • imgeo:RegistratiefGebied
        • nen3610:Spoorbaan
        • nen3610:Terrein
          • imgeo:BegroeidTerreindeel
          • imgeo:OnbegroeidTerreindeel
        • nen3610:Water
          • imgeo:OndersteunendWaterdeel
          • imgeo:Waterdeel
        • nen3610:Weg
          • imgeo:OndersteunendWegdeel
          • imgeo:Wegdeel

Opmerkingen over bovenstaande hiërarchie:

  1. Voor ieder concept in de IMGeo Gegevenscatalogus is hier een linked data klasse aangemaakt. Deze zijn vervolgens onder de generieke klasse imgeo:IMGeoObject geplaatst, alsook onder de relevante NEN 3610 klasse. Is het altijd logisch om een IMGeo klasse aan te maken, of kunnen sommige klassen beter worden opgenomen in het informatiemodel, gebruik makend van SHACL?
  2. Soms lijkt er sprake te zijn van onnodige duplicatie tussen de IMGeo en NEN3610 modellen. Is het bijvoorbeeld wenselijk om een aparte imgeo:NEN3610ID klasse aan te maken, of is hergebruik van de bestaande nen3610:Identificatie klasse, eventueel in combinatie met een BGT-specifieke SHACL definitie, hier wenselijker?
  3. Er lijken een aantal mogelijkheden te zijn om de IMGeo klassen beter te integreren met de NEN 3610 klassen, bijvoorbeeld imgeo:Spoor onder nen3610:Spoorbaan (maar dat moet dan natuurlijk wel semantisch kloppen).

3.4.4 BGT data model

Zie ook VocBench (beperkte toegang).

3.5 Relatie tot NEN 3610

NEN 3610 is het gestandaardiseerde basismodel voor informatiemodellen. NEN 3610 wordt beheerd door Geonovum en toegepast binnen de Nederlandse overheid. Voor NEN3610 is al een linked data versie beschikbaar. Deze wordt eveneens door Geononum beheerd. In de NEN 3610 worden linked data klassen zoals nen3610:Gebouw en nen3610:Weg opgenomen. Deze zijn subklassen van het generiekere nen3610:GeoObject.

Voor de centrale concepten in het BGT semantische model zijn nieuwe klassen aangemaakt zoals bgt:Pand en bgt:Wegdeel. Deze semantisch betekenisvolle BGT klassen zijn subklassen van hun dichtsbijzijnde NEN 3610 klassen. Bijvoorbeeld bgt:Pand is een subklasse van nen3610:Gebouw. bgt:Wegdeel is een subklasse van nen3610:Weg. Omdat deze centrale klassen in de BGT subklassen zijn van klassen in NEN3610, zijn alle in de BGT beschreven IMGeo-objecten instanties van de bestaande nen3610:GeoObject klasse.

Merk op dat de linked data BGT uitdrukkelijk geen klasse bevat die een generiek “BGT object” (of een “IMGeo object”) aanduidt. De reden hiervoor is dat een dergelijke object klasse geen semantische betekenis heeft, en dus niet thuishoort in het semantische model. Tegelijkertijd komt een dergelijk generiek BGT object wel voor in de BGT gegevenscatalogus. Een generiek BGT object maakt het namelijk mogelijk om de eigenschappen die door alle individuele BGT objecten gedeeld worden op een eenvoudige wijze te specificeren. Een dergelijk coördinerend generiek BGT object komt daarom wel voor in het BGT linked data informatiemodel (zie shape:Object).

3.6 Basale structuur van het linked data model

De meest basale structuur van de linked data BGT is te zien in onderstaande afbeelding:

  • De BGT objecten zijn instanties van de bestaande nen3610:GeoObject klasse.
  • De identificatie van BGT objecten is gemodelleerd in instanties van de bestaande nen3610:Identificatie klasse. BGT objecten linken naar hun bijbehorende identificatie middels de nen3610:identificatie relatie.
  • De registratie van BGT objecten is gemodelleerd in instanties van de foaf:Document klasse. BGT objecten linken naar hun bijbehorende document middels de foaf:isPrimaryTopicOf relatie.
  • Via NEN 3610 maakt de linked data BGT dataset tevens hergebruik van de OGC standaarden: nen3610:GeoObject is een subklasse van geo:Feature (open pijlen duiden de subklasse relatie aan).
  • Ten slotte is er een nieuwe klassen aangemaakt om de BGT bronhouders mee aan te duiden.
classDiagram class bgt_Bronhouder { } link bgt_Bronhouder "https://data.labs.kadaster.nl/kadaster/bgt/def/Bronhouder" "" class foaf_Document { bgt_inOnderzoek xsd_boolean bgt_publicatiedatumLandelijkeVoorzieningen xsd_dateTime nen3610_beginGeldigheid xsd_date nen3610_eindGeldigheid xsd_date prov_generatedAtTime xsd_dateTime prov_invalidatedAtTime xsd_dateTime } link foaf_Document "https://triplydb.com/none/foaf/browser?resource=http%3A%2F%2Fxmlns.com%2Ffoaf%2F0.1%2FDocument" "" class geo_Feature { } link geo_Feature "https://triplydb.com/ogc/geo/browser?resource=http%3A%2F%2Fwww.opengis.net%2Font%2Fgeosparql%23Feature" "" geo_Feature --|> geo_SpatialObject class geo_SpatialObject { } link geo_SpatialObject "https://triplydb.com/ogc/geo/browser?resource=http%3A%2F%2Fwww.opengis.net%2Font%2Fgeosparql%23SpatialObject" "" class nen3610_GeoObject { bgt_relatieveHoogteligging xsd_integer bgt_status bgt_Status() } link nen3610_GeoObject "https://triplydb.com/geonovum/nen3610/browser?resource=http%3A%2F%2Fdefinities.geostandaarden.nl%2Fdef%2Fnen3610%23GeoObject" "" nen3610_GeoObject --|> geo_Feature nen3610_GeoObject --> bgt_Bronhouder: bgt_bronhouder nen3610_GeoObject --> foaf_Document: foaf_isPrimaryTopicOf nen3610_GeoObject --> nen3610_Identificatie : nen3610_identificatie class nen3610_Identificatie { nen3610_lokaalID xsd_string nen3610_namespace xsd_string } link nen3610_Identificatie "https://triplydb.com/geonovum/nen3610/browser?resource=http%3A%2F%2Fdefinities.geostandaarden.nl%2Fdef%2Fnen3610%23Identificatie" ""

3.7 Pand klasse

Onderstaande figuur laat zien hoe BGT panden worden gemodelleerd in linked data. Merk op dat BGT panden instanties zijn van de bgt:Pand klasse. Daarmee zijn ze tevens instanties van de nen3610:Gebouw klasse.

BGT panden hebben een relatie tot de BAG panden (bag:Pand). Zowel de BGT alsook de BAG bevatten een versie van de geometrie van het pand. In de BGT is deze geometrie gemodelleerd als een vlakgeometrie (instanties van klasse gml:Surface).

Merk op dat het dubbele voorkomen van pand geometrieën, in de BGT en in de BAG, in de linked data situatie eigenlijk niet nodig is: het kopiëren van informatie uit de BAG en het opslaan en verwerken van deze informatie in de BGT is een anachronisme uit de tijd waarin de basisregistraties nog als silo's werden aangeboden.

classDiagram class bag_Pand { bag_oorspronkelijkBouwjaar xsd_integer bag_status bag_Status() } bag_Pand --|> geo_Feature link bag_Pand "https://data.labs.kadaster.nl/kadaster/bag/browser?resource=http%3A%2F%2Fbag.basisregistraties.overheid.nl%2Fdef%2Fbag%23Pand" "" bgt_Pand --|> nen3610_Gebouw bgt_Pand --> bag_Pand : bgt_bagPand bgt_Pand --> gml_Surface : geo_hasDefaultGeometry link bgt_Pand "/kadaster/bgt/def/Pand" "" geo_Feature --|> geo_SpatialObject link geo_Feature "https://triplydb.com/ogc/geo/browser?resource=http%3A%2F%2Fwww.opengis.net%2Font%2Fgeosparql%23Feature" "" geo_Geometry --|> geo_SpatialObject link geo_Geometry "https://triplydb.com/ogc/geo/browser?resource=http%3A%2F%2Fwww.opengis.net%2Font%2Fgeosparql%23Geometry" "" link geo_SpatialObject "https://triplydb.com/ogc/geo/browser?resource=http%3A%2F%2Fwww.opengis.net%2Font%2Fgeosparql%23SpatialObject" "" class gml_Surface { geo_asGML geo_gmlLiteral geo_asWKT geo_wktLiteral } gml_Surface --|> geo_Geometry link gml_Surface "https://triplydb.com/ogc/gml/browser?resource=http%3A%2F%2Fwww.opengis.net%2Font%2Fgml%23Surface" "" nen3610_Gebouw --|> nen3610_GeoObject link nen3610_Gebouw "https://triplydb.com/geonovum/nen3610/browser?resource=http%3A%2F%2Fdefinities.geostandaarden.nl%2Fdef%2Fnen3610%23Gebouw" "" class nen3610_GeoObject { bgt_bestaand xsd_boolean bgt_relatieveHoogteligging xsd_integer nen3610_beginGeldigheid xsd_date nen3610_eindGeldigheid xsd_date nen3610_identificatie nen3610_Identificatie() foaf_isPrimaryTopicOf foaf_Document() } nen3610_GeoObject --|> geo_Feature link nen3610_GeoObject "https://triplydb.com/geonovum/nen3610/browser?resource=http%3A%2F%2Fdefinities.geostandaarden.nl%2Fdef%2Fnen3610%23GeoObject" ""

3.8 Wegdeel klasse

In onderstaande figuur wordt een zo volledig mogelijk beeld gegeven van de eigenschappen van BGT wegdelen. Wegdelen zijn prototypisch voor veel van de objecten die in de BGT zijn opgenomen. Zo hebben ze:

classDiagram class bgt_Wegdeel { bgt_fysiekVoorkomen bgt_FysiekVoorkomenWeg() bgt_opTalud xsd_boolean } bgt_Wegdeel --|> nen3610_Weg bgt_Wegdeel --> gml_Curve : bgt_kruinlijn bgt_Wegdeel --> gml_Surface : geo_hasDefaultGeometry link bgt_Wegdeel "https://data.labs.kadaster.nl/kadaster/bgt/Wegdeel" "" geo_Feature --|> geo_SpatialObject link geo_Feature "https://triplydb.com/ogc/geo/browser?resource=http%3A%2F%2Fwww.opengis.net%2Font%2Fgeosparql%23Feature" "" class geo_Geometry { geo_asGML geo_gmlLiteral geo_asWKT geo_wktLiteral } geo_Geometry --|> geo_SpatialObject link geo_Geometry "https://triplydb.com/ogc/geo/browser?resource=http%3A%2F%2Fwww.opengis.net%2Font%2Fgeosparql%23Geometry" "" link geo_SpatialObject "https://triplydb.com/ogc/geo/browser?resource=http%3A%2F%2Fwww.opengis.net%2Font%2Fgeosparql%23SpatialObject" "" gml_Curve --|> geo_Geometry link gml_Curve "https://triplydb.com/ogc/gml/browser?resource=http%3A%2F%2Fwww.opengis.net%2Font%2Fgml%23Curve" "" gml_Surface --|> geo_Geometry link gml_Surface "https://triplydb.com/ogc/gml/browser?resource=http%3A%2F%2Fwww.opengis.net%2Font%2Fgml%23Surface" "" class nen3610_GeoObject { bgt_bronhouder bgt_Bronhouder() bgt_relatieveHoogteligging xsd_integer bgt_bestaand xsd_boolean bgt_relatieveHoogteligging xsd_integer nen3610_beginGeldigheid xsd_date nen3610_eindGeldigheid xsd_date nen3610_identificatie nen3610_Identificatie() foaf_isPrimaryTopicOf foaf_Document() } nen3610_GeoObject --|> geo_Feature link nen3610_GeoObject "https://triplydb.com/geonovum/nen3610/browser?resource=http%3A%2F%2Fdefinities.geostandaarden.nl%2Fdef%2Fnen3610%23GeoObject" "" nen3610_Weg --|> nen3610_GeoObject link nen3610_Weg "https://triplydb.com/geonovum/nen3610/browser?resource=http%3A%2F%2Fdefinities.geostandaarden.nl%2Fdef%2Fnen3610%23Weg" ""

Appendix

A. Klasse overzicht