DisGeo demo 3a Lessons Learned

Geonovum Algemeen
Vastgestelde versie

Deze versie:
https://docs.geostandaarden.nl/disgeo/def-al-dll3a-20220211/
Laatst gepubliceerde versie:
https://docs.geostandaarden.nl/disgeo/dll3a/
Vorige versie:
https://docs.geostandaarden.nl/disgeo/def-al-dll3a-20211022/
Laatste werkversie:
https://geonovum.github.io/disgeo-demo-3a/
Redacteurs:
Linda van den Brink, Geonovum
Gabriella Wiersma, Geonovum
Auteurs:
Marcel Reuvers, Kadaster
Lennart van Bergen, Kadaster
Rob Wenneker, Kadaster
Wouter Beek, Kadaster
Damir Brnobic, Ministerie van BZK
Pano Maria, Geonovum
Dick Krijtenburg, Geonovum
Linda van den Brink, Geonovum
Gabriella Wiersma, Geonovum
Silvy Horbach, Geonovum
Arnoud de Boer, Geonovum
Bart-Jan de Leuw, CGI
Doe mee:
GitHub geonovum/disgeo-demo-3a
Dien een melding in
Revisiehistorie
Pull requests
Rechtenbeleid:

Samenvatting DisGeo High-5

In het kader van DiSGeo zijn er in een High-5 setting nieuwe inzichten opgedaan omtrent de ontwikkeling van de samenhangende objectenregistratie. Deze High-5 is in 3 tijdsperioden uitgevoerd: tussen 23 en 27 augustus 2021, aangevuld met twee dagen in november 2021, en afgerond met 3 dagen in januari 2022. Gedurende de eerste periode is onderzoekend een overkoepelend informatiemodel "Gebouwen" ontwikkeld. In de tweede periode zijn er transponeringsregels geformuleerd die beschrijven hoe je gegevens uit de huidige basisregistraties kunt omzetten naar dit SOR informatiemodel. In de derde periode zijn dit informatiemodel en de transponeringsregels geïmplementeerd in een softwareomgeving.

Het informatiemodel Gebouw dat in deze experimenten is gebruikt is ontwikkeld op basis van de Eisen aan model samenhangende objectregistratie [EMSO] en de huidige basisregistraties BAG, BGT, BRT, en WOZ. Hierbij is de scope gaandeweg vernauwd naar de BAG en de BGT. Het doel van de High-5 was om te beproeven of het mogelijk is naar een samenhangend gegevenslandschap toe te werken, zonder dat de SOR er al is. Dit document beschrijft de inzichten die we verkregen hebben over het modelleren van metadata en historie, over semantische vraagstukken rondom gebouwen, over het koppelen van andere informatiebronnen aan de SOR, over vertaling van huidige informatiebronnen naar de SOR, en over het implementeren van deze vertaling in een op APIs gebaseerde technische omgeving.

Status van dit document

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

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

1. Inleiding

In het kader van Doorontwikkeling in Samenhang van de Geo-basisregistraties (DiSGeo) zorgt Geonovum voor een stapsgewijze informatiemodellering van de Samenhangende Objecten Registratie, de SOR.

De stapsgewijze ontwikkeling van het informatiemodel voor de SOR wordt zo opgezet dat de gegevensspecificaties uit de betrokken basisregistraties (BAG, BGT, BRT en deels de WOZ) op basis van de eisen aan het model, behoudens bepaalde daarin geformuleerde wijzigingen, zo optimaal mogelijk een plek kunnen vinden in de nieuwe omgeving waardoor de aanvullende inspanning voor betrokkenen uit het werkveld in de bijhouding zo klein mogelijk wordt gehouden.

Samenhang
Figuur 1 Semantische laag en basisregistraties

In dit kader is er ook ruimte om in inspirerende onderzoeksweken (High-5's) specifieke onderwerpen te onderzoeken en daaruit lessen te trekken die in het vervolg van de informatiemodellering kunnen worden toegepast.

1.1 Waar komen we vandaan?

Alvorens dieper in de materie te duiken is het belangrijk om de context te begrijpen waarbinnen de huidige ontwikkelingen plaatsvinden. Bij het registreren van gegevens ontstaat er momenteel een tweedeling: aan de ene zijde het object waarnaar de registraties verwijzen, aan de andere zijde de registratieketens. Momenteel staan deze registratieketens centraal. Echter zijn er verschillen tussen ketenprocessen - in semantiek, actualiteit, etc. Om de ketenprocessen op elkaar af te stemmen worden onderlinge relaties gelegd via applicatiekoppelingen. In de praktijk is er echter toch behoefte aan een betere afstemming. Verschillende werkprocessen kunnen dan ondersteund worden vanaf het moment dat er een verandering plaatsvindt aan een object.

Dit houdt in dat het straks mogelijk moet zijn om gegevens te kunnen aanpassen of bekijken per object: we gaan van losse registraties naar samenhangende gegevensobjecten. Op deze manier worden gebruikers niet belast met de manier waarop organisaties de data verwerkt hebben voor hun interne processen.

Het informatiemodel van de SOR moet daarom een samenhangend gegevensmodel zijn. Dit heeft gevolgen voor de wijze van modelleren; in plaats van een model waarin de gegevens centraal staan, gaan we toe naar object-centraal modelleren. Iets dat we in deze High-5 onderzoeken.

1.2 Wat is in deze High-5 onderzocht

Het doel: te beproeven of het mogelijk is de basisregistraties in samenhang te bevragen, waarbij deze samenhang nog niet in de data (in de vorm van relaties tussen instanties) aanwezig is, en zonder de onderliggende registraties of de data die daarin staan aan te passen. De samenhang wordt gerealiseerd door een samenhangende, integrale semantische laag die ervoor zorgt dat vragen over registraties heen kunnen worden gesteld en beantwoord.

Een interessante invalshoek is een mogelijke samenhang met het IGO traject van DisGeo. Een belangrijk inhoudelijk verschil tussen deze High-5 en het IGO-traject is dat men in het IGO kijkt naar integraal gebruik op basis van de beschikbare bronnen, en daarbij uit gaat van de bestaande gegevensstructuren. In het kader van de SOR kijken we primair gebruiksgericht, uitgaande van een samenhangend gegevensmodel; en van daar uit naar de databronnen.

Deze High-5 is in 3 tijdsperioden uitgevoerd. Gedurende de eerste periode, in augustus 2021, is onderzoekenderwijs een overkoepelend informatiemodel "Gebouwen" ontwikkeld. In de tweede periode, in november 2021, is het "Gebouwen" model verder uitgewerkt en zijn er transponeringsregels geformuleerd die beschrijven hoe je gegevens uit de huidige basisregistraties kunt omzetten naar dit informatiemodel. In de derde periode, in januari 2022, zijn dit informatiemodel en de transponeringsregels geïmplementeerd in een softwareomgeving om te beproeven waar je dan tegenaan loopt. De insteek hierbij was om te ervaren in welke mate (60/40 / 70/30 / 80/20) het SOR resultaat haalbaar is op basis van de huidige basisregistraties, en te ontdekken op welke punten data-integratie bij de bronnen wél nodig is.

Samenhang
Figuur 2 Semantisch modelleerwerk

Zoals op de afbeelding te zien is, hebben we gewerkt aan het informatiemodel voor de Samenhangende Objectenregistratie - beperkt tot het deel over gebouwen. Input hierbij waren de eisen aan de DiSGeo inhoud [EMSO], de door het modelleerteam opgestelde modelleerprincipes [MODPR] en de uitwerking die er al was voor enkele generieke onderwerpen [GENDOC]. Daarna zijn er, kijkend naar het IMSOR informatiemodel én de huidige basisregistraties en de data daarin, transponeringsregels opgesteld. Ook is er gekeken naar de aansluiting van een externe databron op het SOR Gebouw. Informatiemodel en transponeringsregels zijn vervolgens toegepast in de samenhangende laag die op basis van de transponeringsregels de orchestratie tussen de afnemende APIs en de bronregistraties verzorgt. Een drietal APIs voor afnemers zijn tenslotte daar bovenop gerealiseerd.

1.3 Hoe doen we dat?

We maken op basis van de eisen aan de DiSGeo inhoud een beknopt informatiemodel, voor een afgebakend onderwerp. We hanteren hierbij zoals gezegd de door Geonovum, in samenwerking met de expertgroep DisGeo informatiemodel, opgestelde DisGeo modelleerprincipes en eerste concept-modelleringen van generieke zaken zoals historie, metadata en levensduur. Het informatiemodel is inclusief:

  1. Begrippenkader (SKOS)
  2. Informatiemodel conform MIM 1.1 (UML)

We passen Model Driven Architecture (MDA) toe. Uit het informatiemodel leiden we ten behoeve van de 2e High5 af:

Samenhang
Figuur 3 Model driven architecture

1.4 Hoofdvragen

  1. “Object centraal modelleren”: Hoe doe je dit waarbij de gegevens van dit object uit verschillende registraties komen met verschillende contexten (definities, historie, …)
  2. Hoe druk je de semantische integratielaag uit als context boven de verschillende registraties, waarin de gegevens zijn zoals ze zijn, en waarvan de integratielaag onafhankelijk is? Is de semantische integratielaag (met data centraal over meerdere registraties) de representatie van de samenhang in gegevenscatalogi?
  3. Wat bedoelen we met een semantische laag?

1.5 Verdiepende vragen

Behandeld:

  1. Lukt het om een RDF model geautomatiseerd af te leiden uit het UML model, conform MIM 1.1?
  2. Zijn er handmatige stappen nodig om het afgeleide RDF model ‘goed’ te maken, zoals bedoeld in het NEN 3610 Linked Data profiel?. 
  3. Moet het informatiemodel een conceptueel of logisch model zijn en waarom? Wat is het verschil tussen de twee?
  4. Op welke wijze zorgen we voor semantiek bij de bron? Hoe borgen we de MDA? M.a.w. hoe richten we de informatie-architectuur in?
  5. Op welke manieren drukken we de relaties tussen objecten (en/of informatieobjecten) uit? Drukken we de samenhang uit met URI’s? Waar ontstaan ze en hoe houden we ze bij?
  6. Zijn er verbeteringen te noemen voor de DisGeo modelleerprincipes (zijn ze houdbaar, zijn ze volledig, etc)?

Wel benoemd, maar nog niet aan toegekomen:

  1. Hoe kunnen we het informatiemodel relateren aan het begrippenkader? Wat is de relatie tussen die twee? En wat wordt de relatie tussen informatiemodel, begrippenkader en de data zelf?
  2. Hoe kunnen we de verschillende producten (SKOS begrippenkader, UML informatiemodel, RDF model) publiceren?
  3. Wat voor afspraken zijn er te maken rondom URI patroon en het gebruik van URIs voor begrippen, ontologie, en data (hierbij aandacht voor URI’s in NL API strategie)?

1.6 Onderzoeksgebied: Gebouwen

Voor deze High-5 is gekozen voor een afgebakend onderzoeksgebied. We richten ons op het onderdeel Gebouwen van de SOR omdat dit onderwerp raakt aan meerdere basisregistraties. Tijdens de High-5 is de scope binnen het onderwerp Gebouwen nog verder vernauwd.

Daarnaast zijn in het kader van gebruik twee beleidsthema's geselecteerd die in samenhang hiermee bevraagd worden:

Aan deze beleidsthema's zijn we in het implementatiedeel van de High-5 niet meer toe gekomen.

1.7 Eerdere DiSGeo-high-5's

In 2019 en 2020 zijn twee High-5's uitgevoerd in het kader van DiSGeo.

  1. DiSGeo Demo 1 - Geodata in samenhang mbv huidige techniek bovenop APIs (eind 2019). Deze is ontwikkeld door Netage en Geonovum in opdracht van BZK.

Uitgangspunt: Maak een demonstrator over geodata in samenhang met behulp van huidige techniek bovenop API's.

Conclusies:

  1. DiSGeo Demo 2 - Geodata in samenhang waarbij wordt getoond wat Linked Data voor DiSGeo kan betekenen (zomer 2020). Deze is ontwikkeld door Kadaster, Provincie Noord-Holland, Netage, IHW, en Geonovum in opdracht van BZK.

Uitgangspunt: Maak een demonstrator geodata in samenhang waarbij wordt getoond wat Linked Data voor DiSGeo kan betekenen.

Conclusies:

1.8 Leeswijzer

Dit document is behoorlijk omvangrijk en beschrijft in feite het verloop en de resultaten van drie experimenteersessies, die op verschillende momenten in de tijd plaatsvonden maar toch één inhoudelijk samenhangende High-5 vormen. Het geheel van deze drie experimenteersessies wordt in dit document beschreven.

De eerste twee experimenteersessies draaiden beide om de semantische modellering en de transponering van oud naar nieuw en hebben we daarom als één geheel beschreven. De derde sessie, waarin de software implementatie plaats vond, hebben we apart beschreven.

Het document valt daarom in verschillende delen uiteen:

2. Scope van de High-5

Tijdens de eerste uren van de eerste High-5 dagen in augustus 2021 hebben we gezamenlijk de scope besproken aan de hand van enkele scope-bepalende vragen.

2.1 Wat is ons startpunt?

Het inhoudelijke startpunt voor ons modelleerwerk is het DiS Geo: Eisen aan model samenhangende objectenregistratie document [EMSO]. De laatste inzichten van de DisGeo werkgroep Inhoud - Gebouwen zijn daarin beschreven. Voor ons van belang in dat document is ook het hoofdstuk Transitie / transponering, waarin beschreven is wat de relatie is tussen SOR inhoud en de huidige registraties. Hoewel de informatiemodellen van de huidige basisregistraties niet ons startpunt zijn, kijken we er wel naar, om te zien hoe deze zich verhouden tot het gewenste SOR model en wat er aan eventuele afleidingsregels nodig is.

2.2 Hoe zit het met 3D representaties van objecten?

Voor deze High-5 is 3D buiten scope. We gaan uit van wat je uit de huidige basisregistraties kan halen, eventueel via afleiding. 3D representaties zitten nu niet in een basisregistratie. De 3D basisvoorziening bevat al wel 3D representaties van BAG/BGT objecten en ook de relatie met deze objecten is vastgelegd; het is dus mogelijk om het 3D model bij een object op te vragen.

2.3 Is de BRT in scope?

We hebben besloten de BRT te parkeren voor deze High-5. De BRT valt wel binnen de scope van de SOR; maar de relatie met BGT en BAG is niet eenvoudig te leggen. In het IGO traject is een analyse gedaan van de verhouding tussen BRT objecten en functies met andere basisregistraties. Zij hebben onder andere gevonden dat er een n op n relatie is tussen BRT en BAG/BGT. Er staan ook gebouwen in de BRT die niet in de BAG/BGT staan. De BRT transponering staat bovendien niet in [EMSO] beschreven.

Hoewel niet eenvoudig, is het wel zeer interessant om in een latere fase naar de BRT te kijken in de context van SOR gebouwen. Je zou aan de hand van het object Gebouw kunnen onderzoeken hoe generalisatie in de semantische laag kan worden gedefinieerd. BRT is tevens interessant omdat het rijk is aan functies, ook voor gebouwen. In de SOR zijn deze BRT gebouwfuncties in samenhang gebracht met de functiebeschrijvingen in de WOZ. Dit heeft geresulteerd in de type lijst bij SOR Gebouw. Gekeken moet worden hoe deze informatie kan worden afgeleid uit de BRT en de WOZ.

2.4 Is de WOZ in scope?

We hebben de WOZ in de eerste dagen van deze High-5 wel meegenomen. Op basis van onze bevindingen hebben we echter besloten om de WOZ voorlopig, in de hierop volgende implementatie-High-5, buiten scope te plaatsen. Het informatiemodel SOR-Gebouw dat we hebben geproduceerd bevat dan ook geen objecttypen en kenmerken die uit de WOZ moeten worden afgeleid.

Uit onze eerste exercities om een transponering op te stellen voor SOR gebouw in relatie tot BAG, BGT en WOZ, bleek met name de WOZ relatie een lastige te zijn. Meer hierover staat met name in § 11.3.1 Vertaling naar SOR-Gebouw en § 11.3.2 Vertaling naar SOR-Gebouwzone.

2.5 Wat is de relatie van energielabels met de SOR?

Het energielabel is typisch een gegeven van buiten de SOR; het moet mogelijk zijn voor een externe partij om dit te koppelen aan een SOR object en in samenhang te bevragen. Daarmee is het energielabel in scope van deze High-5. Het is een mooie use case om externe gegevens aan de SOR te koppelen.

Er is geen informatiemodel energielabels; we baseren ons in deze High-5 op een proza beschrijving.

Van energielabels weten we het volgende:

2.6 Gebouw in de huidige registraties

In de huidige basis- en sectorregistraties zijn er veel gegevens te vinden over een "gebouw". Als input voor deze High-5 hebben we de informatiemodellen van deze registraties genomen:

In onderstaand plaatje hebben we getracht om deze te combineren tot één informatiemodel, zonder scherp te kijken naar de specifieke definitie van gebouw, noch kijkende naar de betekenis van eigenschappen.

gebouw-huidige-registraties
Figuur 4 Gebouw en aanverwante gegevens in huidige registraties

Dit plaatje gebruiken we als startpunt voor de ontwikkeling tijdens de high-5 van een logisch SOR-informatiemodel voor gebouwen. In de loop van de High-5 hebben we, zoals eerder in dit hoofdstuk beschreven, de scope vernauwd door eerst de BRT en later ook de WOZ erbuiten te plaatsen.

De volgende achtergrondinformatie stond bij de modellering tot onze beschikking:

Informatiemodel BAG

Informatiemodel BGT

Informatiemodel BRT

Informatiemodel WOZ

Informatie over energielabels

Informatie over energieafgiftepunten

3. Verkenning van inhoudelijke punten

Tijdens de High-5 dagen in augustus 2021 is gezamenlijk verkend welke inhoudelijke punten, betreffende het realiseren van de SOR inhoud op basis van de inhoud van de huidige basisregistraties, relevant zijn. Niet al deze punten zijn uitgebreid aan de orde geweest. We beschrijven hieronder de besproken punten en geven aan welke nader zijn uitgewerkt in de volgende hoofdstukken.

3.1 Transponering

Transponering is het omzetten van gegevens uit de huidige basisregistraties naar SOR gegevens. In deze omzetting zijn allerlei gradaties waar te nemen. Soms gaat het om gegevens die rechttoe rechtaan 1 op 1 te mappen zijn. Hieraan hebben we in deze High-5 geen speciale aandacht verleend. Er zijn ook gegevens die niet 1 op 1 van een basisregistratie over te nemen zijn naar de SOR. Denk hierbij vooral aan afgeleide gegevens, geaggregeerde gegevens of aan gegevens die een betere benaming hebben gekregen. Al deze vormen van omzetten van gegevens bij elkaar worden in dit document ook wel transponering genoemd. Deze term wordt ook gebruikt in [EMSO].

Een eenvoudige vorm van transponering is het wijzigen van de naam van objecttypen, attribuutsoorten en andere modelelementen. Hierbij bestaan complicerende factoren zoals:

Voor de transponering kun je regels formuleren, maar de vraag is dan nog hoe je deze vastlegt. Liefst op een manier die ontwikkelaars eenduiding kunnen interpreteren, maar tegelijkertijd nog wel leesbaar voor niet-programmeurs. Ook hier hebben we naar gekeken.

De verschillende aspecten van transponering zijn tijdens deze High-5 bekeken. Zie hiervoor:

3.2 Identificaties

Op dit moment is er geen unieke, eenduidige identificatie van een SOR object. Als het SOR object niet één op één in een basisregistratie is geregistreerd, heeft het in elke basisregistratie waar het voorkomt een eigen identificatie. Een SOR Gebouw heeft bijvoorbeeld een BAG identificatie, een BGT identificatie en een BRT identificatie. Deze identificaties zijn van belang omdat ze de herkomst van het object duiden. We kunnen echter niet drie attributen genaamd identificatie opnemen, dan zou er een naamgevingsconflict ontstaan. Naast deze bronidentificaties is het wellicht ook van belang om een SOR identificatie in te voeren. Hierbij speelt de UOI mogelijk een rol. Zie hiervoor het rapport UOI verkenning.

Identificatie van objecten speelt een rol bij de behandeling van historie en tijdreizen, waar we uitgebreider op ingaan in § 5. Modelleren van historie en beantwoorden van tijdreisvragen.

3.3 Kwaliteit

Een ander groot onderwerp dat aandacht vraagt binnen de SOR is de kwaliteit van gegevens, en het bevestigen hiervan door een bronhouder. Het is hierbij niet de bedoeling om kwaliteitscontroles te modelleren, we doen dit alleen als er op inhoud bepaalde regels gelden voor gegevens of een combinatie van gegevens. Het gaat onder andere om metadata die iets over kwaliteit van gegevens zegt, zoals nauwkeurigheid, bronverwijzing, het al dan niet in onderzoek zijn, en controlegegevens.

Als gegevens in samenhang een bepaalde consistentie behoren te hebben, kunnen er regels worden opgesteld die gaan over een bepaalde combinatie van gegevens. Dit geldt bijvoorbeeld bij functie en gebruiksdoel van een gebouw. Bepaalde functies van een gebouw zijn benoemd in de WOZ - geconstateerde functies - en in de BAG - vergunde functies. Wanneer deze niet in samenspraak met elkaar zijn, is het van belang om dit te weten. Dit is WOZ en BAG kennis, die een afnemer (meestal) niet heeft. Wanneer een verblijfsobject als gebruiksdoel kantoorfunctie heeft en de WOZ constateert dat het gebruikt wordt voor wonen, dan is het feitelijke gebruik niet legitiem. Dit zou bijvoorbeeld kunnen worden uitgewerkt voor het thema wonen.

Dit onderwerp is niet in zijn totaliteit uitgebreid aan de orde geweest. Deeluitwerkingen zijn hier beschreven:

3.4 Op gelijke wijze modelleren van generieke gegevens

Bepaalde generieke gegevens zoals gegevens over historie, levensloop, herkomst, enzovoort zouden over registraties heen gestandaardiseerd moeten zijn, maar zijn dit nu niet. Bij het gebruiken van de basisregistraties in samenhang is dit een belemmering. We willen dat het gebruik door afnemers niet onnodig complex/genuanceerd wordt en kijken of dit recht te trekken is. We hebben daarom in deze High-5 onderzocht hoe je dit soort generieke gegevens zou kunnen modelleren zodat gebruik in samenhang mogelijk is. Dit hebben we uitgewerkt voor het onderwerp historie.

Zie hiervoor § 5. Modelleren van historie en beantwoorden van tijdreisvragen.

3.5 Afleiden van relaties tussen objecten

De inhoudelijke eisen aan de SOR [EMSO] vragen in sommige gevallen om het afleiden van relaties tussen objecten, die nu in de bronregistraties niet aanwezig zijn. Deze relaties zijn (voor een deel) geometrisch af te leiden. Het afleiden van deze relaties en het vervolgens administratief uitdrukken van deze relaties heeft als voordeel dat gebruikers, die in deze relaties geïnteresseerd zijn, dit niet opnieuw hoeven doen.

Het gaat bijvoorbeeld om:

Dit onderwerp is niet uitgebreid aan de orde geweest. In § 11.2 Vertaalspecificatie zijn relaties tussen objecten niet meegenomen. Een aantal van zulke relaties is wel beschreven in de eerdere iteratie van Gebouw en Gebouwzone vertaalspecificaties (zie § 11.3.1 Vertaling naar SOR-Gebouw en § 11.3.2 Vertaling naar SOR-Gebouwzone).

3.6 Gegevens uit andere bronnen

Met de SOR willen we ook het stellen van functionele vragen op basis van gegevens uit andere bronnen dan een basisregistratie faciliteren. Daarom moet het mogelijk zijn om externe gegevens te koppelen aan gegevens in een basisregistratie. Dit is niet altijd zo eenvoudig. Een voorbeeld hiervan zijn de energielabels. Deze zijn te koppelen aan BAG, maar niet altijd rechtstreeks aan een verblijfsobject. Regelmatig is er een relatie tussen één energielabel en een hele groep van verblijfsobjecten.

Het koppelen van externe gegevens is nader beschreven in § 7. Gegevens koppelen tussen een SOR Gebouw en een andere informatiebron.

3.7 Van functionele eisen aan inhoud naar informatiemodel

Bij het maken van het informatiemodel voor SOR Gebouw, op basis van de eisen aan de inhoud zoals beschreven in [EMSO], lopen we mogelijk tegen semantische dilemma's aan. Hoewel de eisen aan de inhoud zo goed als mogelijk beschreven zijn, is het onvermijdelijk dat we op problematische zaken stuiten als we daadwerkelijk gaan modelleren: dan moeten we immers echt gaan zorgen dat alle details kloppen. Inconsistenties in definities zijn dan bijvoorbeeld problemen die opgelost moeten worden.

Tijdens het modelleerwerk in deze High-5 hebben we met verschillende van dit soort problemen te maken gehad. Deze zijn samengevat in .

3.8 Publicatievorm(en) van het informatiemodel

Omdat er op deze High-5 een vervolg komt waarin het informatiemodel wordt geimplementeerd in software, is het belangrijk dat het informatiemodel wordt opgeleverd in een voor ontwikkelaars bruikbare vorm.

Hoe we dit doen is beschreven in § 14. Benodigdheden ten behoeve van API's.

4. Modelleerpatronen voor metadata

4.1 Modelleerpatroon voor herkomstmetadata

Onder herkomstmetadata verstaan we gegevens die beschrijven hoe een informatieobject tot stand is gekomen. Dit wordt ook wel de audit trail genoemd. Voor dit modelleerpatroon baseren we ons op de W3C standaardenset PROV, in het bijzonder [PROV-DM] en [PROV-O].

[PROV-DM] beschrijft een standaard informatiemodel om herkomst (provenance) te definiëren, en definieert provenance als:

provenance is defined as a record that describes the people, institutions, entities, and activities involved in producing, influencing, or delivering a piece of data or a thing

In het kader van de SOR willen we het vooral hebben over de herkomst van "a piece of data", ofwel herkomst van informatieobjecten.

Voor het begrip introduceren we een Nederlandse vertaling van een subset van het PROV model.

metadata-herkomst
Figuur 5 Nederlandse vertaling van het W3C PROV model

Voor de herkomst van een informatieobject in de SOR kunnen we een informatieobject als een instantie van (een subtype van) een prov:Herkomstentiteit beschouwen. De herkomst van een prov:Herkomstentiteit kan middels het model vrij uitgebreid beschreven worden, waarbij de afleiding of generatie van een entiteit, de activiteiten die daarbij een rol speelden, en de actoren die handelden of verantwoordelijk zijn, in een keten (audit trail) uitgedrukt kunnen worden.

4.1.1 Modelleerpatroon voor brongegevens

De [EMSO] stelt eisen aan de bronverwijzing als metadata van informatieobjecten. Zie de volgende passage uit [EMSO]:

Bronverwijzing betreft aan de ene kant de formele onderbouwing van gegevens, bijvoorbeeld in de vorm van formele brondocumenten, zoals vergunningen en besluiten, maar aan de andere kant ook de meer technische bron van de gegevens, zoals plaatsbepalingspunten en indirect luchtfoto's, metingen en BIM-modellen.

Gezien deze eisen is het van belang om een modelleerpatroon te formuleren voor het vastleggen van metadata voor brongegevens, opdat dit voor alle informatieobjecten in de SOR op een standaardmanier kan worden toegepast.

Naast de eisen in [EMSO], zijn er ook modelleerprincipes geformuleerd in [MPSOR] die er voor zorgen dat het object centraal wordt gesteld, zodat samenhang gerealiseerd kan worden. Eén van de modelleerrichtlijnen luidt:

Scheidt registratie-, bron- en herkomstmetadata van directe eigenschappen

Dit houdt in dat we bron- en herkomstmetadata niet op hetzelfde niveau als normale objecteigenschappen zoals bouwjaar en oppervlakte willen uitdrukken. De reden hiervoor is dat directe eigenschappen over het object gaan, en bron- en herkomstmetadata over de informatie over het object.

We hebben dus een aanknopingspunt voor bron- en herkomstmetagegevens nodig dat wel te relateren is aan het beschreven object, maar niet als directe gegevens over het object wordt uitgedrukt. De nieuwe [NEN3610-2021-ontw] biedt uitkomst. Daarin is dit aanknopingspunt al geformuleerd.

nen3610-registratiegegevens
Figuur 6 NEN 3610 (2021 ontwerp) - Registratiegegevens van GeoObject

De [NEN3610-2021-ontw] schrijft al voor hoe tijdlijnen en versieinformatie van informatieobjecten uitgedrukt kunnen worden, los van de directe gegevens over het object middels het construct Registratiegegevens.

In dit patroon nemen we Registratiegegevens als aanknopingspunt voor opname van verdere bron- en herkomstgegevens. Dit doen we door Registratiegegevens als (subtype van) prov:Herkomstentiteit te beschouwen (Figuur 7).

metadata-herkomst-bron
Figuur 7 Toepassing van W3C PROV en NEN 3610 (2021 ontwerp) voor bron en herkomstgegevens

Vervolgens introduceren we de mogelijkheid om verschillende soorten Bronentiteit te definiëren die als primaireBron opgenomen kunnen worden voor een informatieobject. Hierbij maken we gebruik van een standaard [PROV-DM] modelleerpatroon (primary source). Hiermee maken we het bijvoorbeeld mogelijk om een brondocument, of andere bronnen zoals luchtfoto's op een standaard manier op te nemen als bron van een informatieobject. Daarnaast kunnen we zowel deze bronentiteiten, als het informatieobject zelf, toeschrijven aan een verantwoordelijke partij. In het geval van het SOR informatieobject is dat een overheidsorganisatie, maar een bronentiteit zou best van een niet-overheidspartij afkomstig kunnen zijn.

Noot

4.1.2 Modelleerpatroon voor de beschrijving van de afleiding van SOR-informatieobjecten

De implementatie van de SOR zal gefaseerd aangepakt gaan worden. Tijdens deze High-5 verkennen we hoe we in de eerste fase de SOR kunnen neerzetten als een ontsluitingslaag over de verschillende registraties heen. Daarbij zal een SOR-informatieobject dus afgeleid worden kunnen worden uit één of meer informatieobjecten uit onderliggende basisregistraties.

Het is dan ook belangrijk om te kunnen duiden uit welke informatieobjecten een SOR informatieobject is samengesteld, ofwel wat de herkomst van een SOR informatieobject is.

Voor dit doeleinde kunnen we wederom gebruikmaken van het PROV raamwerk voor het opstellen van een modelleerpatroon.

metadata-herkomst-afleiding
Figuur 8 Toepassing van W3C PROV en NEN 3610 (2021 ontwerp) voor de beschrijving van de afleiding van SOR-informatieobject

Hierbij maken we gebruik van een standaard [PROV-DM] modelleerpatroon (derivation), waarbij een entiteit wordt afgeleid uit één of meerdere andere entiteiten. Op deze manier kan een Registratiegegevens instantie uit de SOR, gekoppeld worden met een Registratiegegevens instantie uit de onderliggende basisregistraties, waarmee we uitdrukken uit welke informatieobjecten een SOR-informatieobject is samengesteld.

Noot

5. Modelleren van historie en beantwoorden van tijdreisvragen

Bij dit inhoudelijke punt wordt gekeken hoe gegevens uit verschillende onderliggende bronnen te combineren zijn, in het bijzonder voor aspecten die te maken hebben met de historie van gegevens en tijdreizen. De punten waarop gelet moet worden zijn benoemd en er is een vertaalspecificatie gemaakt om historie "in elkaar te schuiven".

5.1 Doel

Een uniforme manier voor afnemers:

1) om te zien wanneer gegevens geldig zijn en wanneer deze gegevens geregistreerd/beschikbaar zijn;

2) om een tijdreis vraag te stellen.

Deze tijdreisvragen zijn (ook) los aan de basisregistraties te stellen. In deze High-5 echter wordt de tijdreisvraag "door een afnemer" 1x gesteld aan de SOR c.q. het SOR object Gebouw, en wordt deze tijdreis "onder water" aan de basisregistraties gesteld. Hierna worden de gegevens van de basisregistraties over een Gebouw die op de gevraagde datums geldig en beschikbaar zijn "in elkaar geschoven". De specificatie voor dit in elkaar schuiven en de uitkomst ervan worden hieronder beschreven.

Noot

5.2 Uitgangspunten

Dit betekent voor dit inhoudelijke punt:

5.3 Uitdaging en bijzondere punten

De uitdaging is om data uit de onderliggende basisregistraties uit te leveren maar dan geuniformeerd. D.w.z. dat historie wordt bijgehouden in of over versies van informatieobjecten. Een versie is een setje gegevens over een object, zoals deze gedurende een bepaalde periode onveranderd zijn, en over die set gegevens wordt de tijdlijn geldigheid en de tijdlijn registratie bijgehouden en uitgeleverd.

De uit te werken bijzondere punten voor historie en tijdreizen zijn:

  1. Definities van de tijdlijn geldigheid en de tijdlijn registratie.
  2. Als we het object centraal stellen, hoe gaan we dan om met informatieobjecten over hetzelfde object uit 2 of meer basisregistraties die we in elkaar schuiven, in het bijzonder met meerdere identificaties.
  3. Niet elke geo-basisregistratie kent nu beide tijdlijnen. Maar informatie over wanneer gegevens geldig en beschikbaar/geregistreerd zijn is wel beschikbaar.
  4. Niet elke geo-basisregistratie heeft voor de tijdlijn geldigheid hetzelfde dataype, sommige gebruiken een datum, sommige een datumtijd of een timestamp. Hoe gaan we hiermee om?
  5. Mutatieverschillen, met name t.a.v. het einde van levenscycli van objecten, wat bv. de BGT doet met een einddatum geldigheid en de BAG met een eindstatus.
  6. Hoe schuif je versies van informatieobjecten uit verschillende basisregistraties in elkaar; wat is het algoritme?

Ad 0. definities van tijdlijn geldigheid en tijdlijn registratie

Zie [NEN3610-2021-ontw] historie.

Merk op:

Ad 1. in elkaar schuiven van versies van informatieobjecten uit meerdere basisregistraties of bronnen

Een SOR object kan en mag meerdere identificaties hebben. Het voordeel hiervan is dat de link naar de basisregistratie(s) bekend is.

Ad 2. niet elke geo-basisregistratie kent nu beide tijdlijnen

Om de geldigOp tijdreis vraag (welke gegevens waren bekend binnen een bepaald tijdvak) te kunnen stellen moet een basisregistratie weten wanneer de gegevens geldig zijn. Elke basisregistratie hoort te weten wanneer de gegevens die erin geregistreerd zijn geldig zijn. Deze tijdlijn geldigheid wordt echter niet altijd fysiek vastgelegd. Als dit niet zo is, dan is het nodig om deze af te leiden. Vertaal dan wat er geregistreerd is in de basisregistratie naar de gevraagde tijdlijnen.

Elke basisregistratie die aansluit op de SOR moet kunnen:

Vertaalspecificatie tijdlijnen:

Alleen de BGT heeft dus een vertaalspecificatie nodig voor de tijdlijn geldigheid. De BGT kan dit het beste zelf aangeven. Denk bv. aan:

Aanname is dat de BGT dit kan en doet.

Ad 3. Niet elke geo-basisregistratie heeft voor de tijdlijn geldigheid hetzelfde dataype

Vertrekpunt van de SOR is dat een afnemer een vraag stelt: welke gegevens zijn er geldig op een bepaalde datum, veelal vandaag. Een gewone afnemer gaat niet zo snel een timestamp opgeven in deze vraag. Voor basisregistraties worden besluiten ook genomen op dagbasis. Het is wel zo dat als er twee versies van een informatieobject op dezelfde dag geldig zijn/worden dat de laatste van de twee het antwoord is op de vraag: "wat is er vandaag geldig".

Voor wat betreft het datatype voor geldig op en het datatype voor begin en einde geldigheid, is hier een keuze te maken voor de SOR.

Optie a) We gebruiken altijd een DatumTijd voor geldigheid. In basisregistraties die alleen een datum kennen, gebruiken we die datum en dan 00:00:00.

Optie b) We volgen bij de tijdlijn geldigheid de definitie van de basisregistratie. Daarom: gebruik een keuze tussen datatypes.

Optie c) We gebruiken altijd een Datum. Immers, besluiten voor basisregistraties gaan in op een datum. We willen ernaar toegroeien dat de tijdlijn geldigheid altijd een datum is. Dit is nu al te implementeren, mits ofwel de basisregistratie ofwel de SOR view erop goed omgaat met meerdere versies op 1 dag.

Advies: gezien het groeipad willen we onderzoeken of c) mogelijk is.

KEUZE: C

Ad 4. Mutatieverschillen

Wanneer de levenscyclus van een object eindigd en de basisregistratie geen eindstatus kent, dient een basisregistratie te zorgen voor ofwel de registratie, ofwel het afleiden, van een extra versie met wel een eindstatus. Het is aan de basisregistratie om te kiezen of er wel of niet een versie met een eindstatus wordt geregistreerd of dat deze wordt afgeleid.

Ad. 5 Hoe schuif je versies van informatieobjecten uit verschillende basisregistraties in elkaar

Onderstaande een verkenning, die uitgaat van alle genoemde keuzes in de voorliggende tekst.

basisregistratie 1:

- versie 1, begin geldigheid t1 -  

basisregistratie 2:

- versie 1, begin geldigheid t3 -  

SOR:

Stel vraag aan basisregistratie 1: geldigOp t4. 
Antwoord: versie 1. gebruik deze gegevens voor het SOR informatieobject.
Stel vraag aan basisregistratie 2: geldigOp t4. 
Antwoord: versie 1. gebruik deze gegevens voor het SOR informatieobject.

Maar hoe doen we het met de tijdlijnen?

Optie 0: lever de losse antwoorden uit de losse basisregistraties ook los door, maar wel technisch in hetzelfde antwoord en bij elkaar.

--> 1 versie in basisregistratie 1 en 1 versie in basisregistratie 2 = 2 losse versies 
(niet in elkaar geschoven). 

Optie 1: laat elke basisregistratie heel duidelijk terugkomen in het SOR informatieobject

Bv. een gegevensgroep voor gegevens uit basisregistratie 1 + de metagegevens voor historie uit basisregistratie 1 en voor basisregistratie 2 analoog.

--> 1 versie in basisregistratie 1 en 1 versie in basisregistratie 2 = 1 versie van het SOR informatieobject, 
bestaande uit de delen die elk afzonderlijk tijdlijnen hebben. 

Optie 2: plaats alle kenmerken in het SOR informatieobject en bereken voor elk setje gegevens eigen tijdlijnen.

Introduceer nieuwe versies voor elke periode.

--> 1 versie in basisregistratie 1 en 1 versie in basisregistratie 2 = 2 versies van het SOR informatieobject, 
met elk afzonderlijk tijdlijnen. 

Deze laatste is het meeste in lijn met de intentie van de SOR en met de insteek: bepaal van elke setje gegevens wanneer dit setje geldig is.

KEUZE: voor deze exercitie gaan we uit van optie 2, om te kijken of dat goed kan. De voorbeelden die we gaan uitwerken in de volgende paragrafen zijn hiermee in lijn.

Illustratieve voorbeelden

Dezelfde voorbeelden hebben we ook uitgewerkt met de tijdlijn registratie erbij. Uitgaande van:

KEUZE Dit is een regel die voor de BAG en de BRK geldt. Deze is toegepast. Dit past binnen NEN3610.

De voorbeelden worden dan als volgt uitgebreid:

Ook voor andere, complexere voorbeelden zullen we uitwerkingen moeten maken. Onder andere een voorbeeld met meerdere geldige versies op één dag, met een registratietijdstip waarvan de begin geldigheid op een latere tijd ligt dan het registratie tijdstip van de eind geldigheid. De vertaalspecificatie wordt wellicht minder rechttoe rechtaan.

5.4 Modellering van historie in de SOR

Het informatiemodel gaat uit van het modelleerpatroon van [NEN3610-2021-ontw] waarbij Registratiegegevens over het informatieobject, zoals de tijdlijn geldigheid en tijdlijn registratie in een apart metadata objecttype zitten, dat 1 op 1 gerelateerd is aan het objecttype waar het informatieobject over gaat. Dit tezamen met de modelleerprincipes van de SOR, zorgt er voor dat het object centraal gehouden kan worden, ofwel, dat het objecttype alleen directe eigenschappen van het object kent.

sor-modellering-historie
Figuur 9 Historie van informatieobjecten in de SOR

Het informatiemodel biedt, zoals beschreven in § 4.1.2 Modelleerpatroon voor de beschrijving van de afleiding van SOR-informatieobjecten, ook de mogelijkheid om de herkomst van een SOR informatieobject uit te drukken. Hierbij kan bij de registratiegegevens via afgeleidVan relaties een koppeling gelegd worden met de registratiegegevens van informatieobjecten uit onderliggende registraties. In informatieproducten kan dan gekozen worden om deze herkomstinformatie wel of niet te tonen.

Noot
Noot

Een informatieobject in een concrete serialisatie conform dit modelleerpatroon zou er bijvoorbeeld als volgt uit kunnen zien:

5.5 Uitwerking: voorbeelden uitgewerkt met tijdreisvragen

Op basis van de keuzes zoals gemaakt in dit hoofdstuk werken we hier een fictief complexer voorbeeld uit op basis van het BAG historiemodel, waarin gegevens inactief gemaakt zijn.

Uitgangssituatie

Obj. ID Versie Waarde BG EG TR ER TI
1000 1 A 01-01-2018 03-03-2019 30-12-2017 01-03-2019
1000 2 B 03-03-2019 01-09-2033 01-03-2019 01-04-2019 01-05-2019
1000 3 H 01-09-2033 01-04-2019 01-05-2019
1000 4 B 03-03-2019 01-05-2019

Fictief voorbeeld uit de WOZ

Obj. ID Versie Waarde BG EG TR ER
2000 0 200k 01-01-2019 01-01-2020 10-01-2019 20-02-2020
2000 1 220k 01-01-2020 20-02-2020

5.5.1 Insteek 'versies': stel de tijdreis vraag aan elke basisregistratie en voeg de antwoorden samen

De tijdreisvraag aan een SOR Gebouw kent maar 1 geldigOp en 1 beschikbaarOp. Stel deze tijdreisvraag aan de basisregistraties die gebruikt worden om het SOR Gebouw samen te stellen. Elk basisregistratie zal als antwoord éém versie van een informatieobject opleveren - met een setje gegevens erin - en deze versie kent een tijdlijn geldigheid en een tijdlijn registratie. De tijdlijn van registratie komt doorgaans overeen met het moment van beschikbaarstelling en als dit zo is, dan kunnen de gegevens, maar ook de tijdlijnen, samengevoegd worden.

Oftewel, doe een tijdreis op de BAG en de WOZ en breng de gegevens samen in een SOR Gebouw.

Lange formulering: welke gegevens zijn geldig voor dit gebouw op 'datum', met de kennis/data die vanuit de informatievoorziening beschikbaar is/was op 'datumtijd'. De eerste datum wordt gebruikt voor de tijdreis parameter geldigOp en de tweede voor beschikbaarOp. De tijdsreis wordt beantwoord door eerst alle gegevens weg te filteren die na beschikbaarOp in de registatie zijn geregistreerd (inclusief einddatum geldigheid en eind registratie). Van de gegevens die overblijven wordt de geldigOp vraag gesteld. Deze vragen worden "onder water" aan de BAG gesteld en aan de WOZ.

Korte formulering: welke gegevens zijn geldig op 'datum geldigOp' en beschikbaar op 'datumtijd beschikbaarOp'?

5.5.1.1 Vertaal specificatie

We ontvangen van de onderliggende basisregistraties één versie van een informatieobject, die geldig en beschikbaar is op de gevraagde tijdreis. Dat wil zeggen, data die op de gevraagde beschikbaarOp aanwezig was in de registratie. We ontvangen géén data die naderhand is geregistreerd; hieronder vallen ook later ingevulde data zoals 'einde geldigheid', 'eind registratie' en 'tijdstip inactief'.

1) Als een gegeven er is, neem deze op in SOR Gebouw.

2) Als een gegeven er niet is, maar wel zou moeten zijn volgens IMSOR - Gebouw, vul deze in als nillable=true (afhankelijk van gekozen serialisatietaal).

3) Bereken de juiste waardes voor de historie / tijdlijn attributen.

  • Begin Geldigheid (BG): je krijgt er twee, één van BAG, één van WOZ, kies de nieuwste/laatste die voor/gelijk aan 'geldigOp' ligt/is.
  • Eind Geldigheid (EG): je krijgt er twee, één van BAG, één van WOZ, kies de vroegste/eerste die na/gelijk aan 'geldigOp' ligt/is.
  • Tijdstip Registratie (TR): je krijgt er twee, één van BAG, één van WOZ, kies de TR die hoort bij de geselecteerde BG.
  • Eind Registratie (ER): je krijgt er twee, één van BAG, één van WOZ, kies de ER die hoort bij de geselecteerde EG.

4) Neem de identificaties van de objecten uit onderliggende informatieobject en overige data die erbij hoort over in de (optionele) 'herkomst data'.

Noot
5.5.1.2 Tijdreisvragen
Noot

5.5.2 Insteek 'levenscycli': vraag de geldige levenscycli op met een tijdreis en voeg deze samen

Een andere insteek is om de levenscyclus van de BAG en die van de WOZ op te vragen en om op basis hiervan de gegevens samen te voegen. Dit is ook nodig als een afnemer de levenscyclus van een SOR gebouw opvraagt. Voor tijdreizen is het altijd zo dat een afnemer naar geldige gegevens vraagt, met de kennis die de informatievoorziening had over de objecten. Het is dus niet nodig om de hele levenscyclus op te vragen. Het volstaat om de geldige levenscyclus op te vragen op de aangegeven beschikbaarOp. Nadat deze in elkaar geschoven zijn kan aan het resultaat - de geldige levenscyclus van het SOR Gebouw - gevraagd worden wat de geldige gegevens zijn op de aangegeveven geldigOp.

Uitgangssituatie (gelijk aan eerder genoemde)

Obj. ID Versie Waarde BG EG TR ER TI
1000 1 A 01-01-2018 03-03-2019 30-12-2017 01-03-2019
1000 2 B 03-03-2019 01-09-2033 01-03-2019 01-04-2019 01-05-2019
1000 3 H 01-09-2033 01-04-2019 01-05-2019
1000 4 B 03-03-2019 01-05-2019

TI staat voor tijdstip inactief. Deze gegevens waren geldig tot 01-05-2019 maar zijn dit hierna niet meer.

Obj. ID Versie Waarde BG EG TR ER
2000 0 200k 01-01-2019 01-01-2020 10-01-2019 20-02-2020
2000 1 220k 01-01-2020 20-02-2020
5.5.2.1 Vertaal specificatie
  • Doe een tijdreis naar de geldige levenscyclus van de BAG, zoals beschikbaar op een bepaalde datum.
  • Doe een tijdreis naar de geldige levenscyclus van de WOZ, zoals beschikbaar op een bepaalde datum.
  • Schuif deze in elkaar.
  1. Controleer of elke levenscyclus alleen geldige gegevens/versies bevat. BAG: geen gegevens met bv. tijdstipNietBAG of tijdstip inactief. WOZ: vergelijkbare controle indien van toepassing.

  2. Zet alle bron-versies van bron 1 en bron 2 in een lijst op begin datum, en hou per versie de BG en TR (er) bij.

  • Als twee versies dezelfde BG hebben, sorteer ze op TR (oudste eerst).
  • We hebben nu een bron-versie-lijst.
  • Per BG-TR combinatie gaan we 1 versie maken, oftewel als uit bron 1 X versies komen en uit bron 2 Y versies dan maken we X + Y versies.
  1. De einddatums van deze versies moeten nog bepaald worden. Zet alle EG datums op een rij in een bronnen-EG-lijst en hou bij elke EG bij welke ER erbij hoort.

  2. Doorloop de bron-versie-lijst.

  • Neem de eerste versie uit de bron-versielijst: maak een 1e SOR versie met deze BG en bijbehorende TR en plaats deze in de SOR-versie lijst.
  • Neem de 2e versie uit de bron-versielijst: maak een 2e SOR versie met deze BG en bijbehorende TR en plaats deze in ed SOR-versie lijst.
  • Enz.
  1. Bepaal de EG van de SOR-versies in de SOR-versielijst.
  • Geef de 1e SOR versie als EG de datum die voorkomt als BG in de 2e versie.
  • Geef de 2e SOR versie als EG de datum die voorkomt als BG in de 3e versie.
  • Enz.
  1. Bepaal de ER van de SOR-versies in de SOR-versielijst.
  • Doorloop voor elke SOR-versie de bron-EG/ER lijst.
  • Als een SOR-versie een EG heeft:
    • Zoek de 1e EG op in de bronnen-EG-lijst die overeenkomt met de EG van de SOR-versie.
    • Bij een match: neem de bijbehorende ER over naar de SOR-versie. Verwijder deze EG/ER entry uit de bronnen-EG-lijst
    • Bij geen match: neem als TR de TR die hoort bij de BG van de volgende SOR-versie.
  1. Controleer of de tijdlijn geldigheid tussen de SOR versies netjes op elkaar aansluiten.
  • 1e SOR-versie EG = 2e SOR versie BG.
  • 2e SOR-versie EG = 3e SOR versie BG.
  • laatste SOR-versie EG = leeg en heeft een eindstatus.
  1. Bepaal de functionele gegevens van de SOR-versie.
  • Bepaal voor elke SOR-versie:
    • is er overlap op de periode BG-EG van de SOR-versie met een geldige versie van bron 1? Zo ja, voeg de gegevens van deze bron-versie toe aan de SOR-versie.
    • is er overlap op de periode BG-EG van de SOR-versie met een geldige versie van bron 2? Zo ja, voeg de gegevens van deze bron-versie toe aan de SOR-versie.
    • Enz.
    • Bij meerdere SOR-versies op 1 dag: TODO.

Wellicht zijn er betere algoritmes denkbaar. Dat kan uiteraard besproken worden.

5.5.2.2 Tijdreis vragen

Beide insteken komen tot hetzelfde antwoord.

5.6 Aanbevelingen voor vervolg (2e high-5)

Voor de aanbevelingen wordt verwezen naar paragraaf Aanbevelingen met betrekking tot historie

6. Implementatieaspecten van historie

Er zijn verschillende manieren waarop historie in linked data gerepresenteerd kan worden. Deze manieren hebben verschillende voor- en nadelen die we hier inzichtelijk maken.

6.1 Variant 1: Uitspraak reïficatie

In deze variant wordt de historie volledig weergegeven binnen de graaf structuur zelf. De graaf structuur bevat zowel de uitspraken over objecten, alsook de registratieve gegevens die bij die uitspraken horen (bijvoorbeeld begin- en eind geldigheid). Een visuele weergave hiervan is te vinden in Figuur 10.

Het afzonderlijk representeren van uitspraken als op zichzelfstaande entiteiten wordt in linked data “uitspraak reïficatie” genoemd.

Deze variant maakt gebruikt van:

  1. Standaard RDF triples.
  2. RDF uitspraak reïficatie.
  3. Sets van RDF uitspraken
historie-uitspraak
Figuur 10 Historie representatie op basis van uitspraak reïficatie

6.2 Variant 2: Graaf reïficatie

In deze variant wordt de historie weergegeven buiten de graaf structuur. De graaf structuur bevat de uitspraken over objecten. De registratieve gegevens over die uitspraken worden toegekend aan de totale graaf waarin de uitspraken over objecten zich bevinden. Een visuele weergave hiervan is te vinden in Figuur 11.

Het afzonderlijk representeren van grafen als op zichzelfstaande entiteiten wordt in linked data “graaf reïficatie” genoemd.

Deze variant maakt gebruik van:

  1. Standaard RDF triples.
  2. RDF graaf reïficatie.
historie-graaf
Figuur 11 Historie representatie op basis van graaf-reïficatie

6.3 Variant 3: Graaf reïficatie + uitspraak reïficatie

In deze variant wordt de historie weergegeven binnen en buiten de graaf. Binnen de graaf bevinden zich zowel uitspraken over objecten, alsook sommige registratieve gegevens over die uitspraken. Hiervoor wordt binnen de graaf gebruik gemaakt van uitspraak reïficatie. Naast de registratieve gegevens binnen de graaf zijn er ook registratiegegevens die over de graaf zelf gaan. Hiervoor wordt graaf reïficatie toegepast. Een visuele weergave hiervan is te vinden in Figuur 12.

Deze variant maakt gebruik van:

  1. Standaard RDF triples.
  2. RDF uitspraak reïficatie.
  3. RDF graaf reïficatie.
historie-graaf-uitspraak
Figuur 12 Historie opslag op basis van graphs

6.4 Variant 4: Ontkoppeling

In deze variant wordt de representatie van observaties losgekoppeld van de representatie van objecten. Beide representaties worden weergegeven binnen de graaf structuur en zijn verbonden middels een herleidbaarheidsrelatie. Inhoudelijke eigenschappen komen twee keer voor: één keer op het niveau van de observatie en één keer op het niveau van het object. Een visuele weergave hiervan is te vinden in Figuur 13.

Deze aanpak wordt momenteel toegepast binnen IGO.

Deze variant maakt gebruikt van:

  1. Standaard RDF triples.
historie-soc
Figuur 13 Historie representatie op basis van ontkoppeling

6.5 Variant 5: Ontkoppeling + Data Cube

Deze variant lijkt op variant 4, maar maakt gebruik van de Data Cube standaard om de uitspraken over observaties op een gestandaardiseerde manier vast te leggen. Een visuele weergave hiervan is te vinden in Figuur 14.

historie-soc-data-cube
Figuur 14 Historie representatie op basis van ontkoppeling en Data Cube

6.6 Vergelijkingstabel

Tabel 1 ― Vergelijking tussen de voor- en nadelen van de verschillende varianten voor historie representatie in linked data.
12345
duplicatie van eigenschappen+++--
standaards-conform+++-+
metadata opslag op uitspraak niveau+-+-+
technische haalbaarheid: grafen+--++
technische haalbaarheid: reïficatie-+-++

7. Gegevens koppelen tussen een SOR Gebouw en een andere informatiebron

voorbeeld-informatie
Figuur 15 Informatie over een gebouw uit verschillende bronnen

Dit betreft use cases waarin een informatiebron (niet de SOR zelf) wilt koppelen met een object in de SOR, zoals een informatiebron met energiegegevens.

De bronnen waaruit de SOR wordt samengesteld zijn andere bronnen dan waar de energiegegevens worden bijgehouden. Wat in ieder geval niet de bedoeling is, is het overnemen en opslaan van de data uit deze bronnen naar de SOR. In plaats daarvan beogen we een federatief stelsel, waarin de verschillende bronnen worden bevraagd en de data uit deze bronnen in samenhang geleverd kunnen worden aan afnemers. De informatiebron met energiegegevens kan gecombineerd worden met de informatiebron SOR (of een basisregistratie).

In dit geval gaat het niet om het aanbrengen van samenhang tussen gegevens van de basisregistraties onder de SOR. Daarover hebben we in een eerdere High 5 al veel gezegd onder de noemer Governance op het snijvlak.

We hebben het hier over het aanbrengen van samenhang tussen gegevens uit andere bronnen met de data van de SOR. Anders gezegd, de SOR kent de energiegegevens niet, maar de energiegegevens kent wel een SOR object (of basisregistratie object) en door een koppeling hiertussen te leggen zijn beide informatiebronnen integraal te bevragen en kunnen gegevens bij elkaar gebracht worden.

We noemen de niet-SOR bronnen in onderstaande tekst: andere bronnen.

De belangrijkste stap is voor een andere bron om eerst een betrouwbare koppeling te leggen van een andere bron naar de SOR, al dan niet via de BAG, de BGT, de WOZ, enz. Dit is op zichzelf niet eenvoudig. je kan hierbij denken aan een koppeling op basis van een automatische matching op basis van adres, geometrie, of beide.

7.1 Manieren van koppelen

Bij het leggen van een koppeling zijn in theorie verschillende manieren denkbaar. We kijken naar elk van deze en naar de voors en tegens ervan.

Voorbeelden van deze koppelingen zijn:

Uitgangspunten:

1. De koppeling loopt in principe altijd van een "andere" bron naar de SOR.

Voordelen:

Implicaties:

2. Binnen de SOR zelf zijn er koppelingen tussen de BAG en de BGT, de BAG en de WOZ, maar deze zijn voor de gebruikers van de SOR verborgen.

3. Van de SOR naar een andere bron zal er geen koppeling zijn (in theorie wel mogelijk).

4. Een koppeling kan ook gelegd worden als deze zuiver geometrisch kan worden bepaald.

Nadat een koppeling is gelegd, moet deze ook beheerd worden. Maar zodra de koppeling er is, kunnen gegevens uit de SOR en uit de "andere" bron bij elkaar gebracht worden. Hier zijn een aantal opties denkbaar.

7.2 Combineren van de eigen bron met SOR gegevens

Er zijn verschillende modelleerpatronen waaraan gedacht kan worden. Deze patronen hebben we in de High-5 verkend. Elk patroon heeft eigen voordelen en nadelen; er is nog geen voorkeur uitgesproken, en nog geen advies per situatie. We gaan deze opties verder onderzoeken.

Algemeen kunnen we wel de volgende voorwaarden stellen voor een samenhangend stelsel van informatie gekoppeld aan de SOR:

Dat levert de volgende voordelen op:

Daarbij spelen de volgende implicaties:

7.2.1 Voorbeeldcasus

Voor het duiden van deze verschillende modelelerwijzes gebruiken we de voorbeeldcasus uitgebeeld in Figuur 16. We hebben twee "externe" objecttypes Gebouwdeel en MijnGebouw die we op verschillende manieren willen koppelen met Gebouw uit de SOR.

koppelen-voorbeeldcase
Figuur 16 Voorbeeldcasus te koppelen informatiemodellen

7.2.2 Relateren van verschillende objecttypes

7.2.2.1 Optie 1: Koppelen vanuit een andere bron naar de SOR met een relatie

Deze koppeling zou een beheerde relatie kunnen zijn vanuit een andere bron object naar een SOR object. Dit kan op verschillende manieren:

7.2.2.1.1 a: Meegemodelleerd in dataset als relatie

Je kunt een relatie meemodelleren in een dataset door vanuit die dataset een relatie op te nemen naar een SOR-object. De relatie wordt een (nieuwe) eigenschap van een al bestaand object uit de eigen/andere bron.

Om aan te duiden dat deze relatie verwijst naar een extern informatiemodel gebruiken we het stereotype «Externe koppeling» uit [MIM]. Merk op dat we in het externe informatiemodel verwijzen naar objecttype Gebouw uit de SOR. Het doel hiervan is het kunnen verwijzen naar een SOR Gebouw d.m.v. de identificatie van de SOR. Het is, in de representatie als data, belangrijk om niet alleen een directe referentie naar de identificatie op te nemen, maar om daadwerkelijk een objectstructuur van het gerefereerde object op te nemen. Dit laatste maakt het gemakkelijk om datastructuren als het ware over elkaar heen te leggen (zie datavoorbeelden in JSON).

koppelen-relateren-meegemodelleerd
Figuur 17 Relatie met SOR object meegemodelleerd in (externe) dataset

Implicaties

  • Je beheert de relatie bij de andere objectinformatie
7.2.2.1.2 b: Apart beheerde "linkset"

Wanneer je een objecttype uit een bestaande dataset wilt koppelen aan de SOR, zonder het objecttype, of de dataset, zelf aan te passen is het mogelijk om een aparte "linkset" op te stellen. De link van het object A1 naar het SOR object S1 wordt dan buiten het bestaande object beheert, als link. De link bevat alleen de identificatie van A1 en van S1. De link is een aanvulling op het bestaande object, maar wordt wel los beheerd.

Een linkset is niets meer dan een set van relaties tussen instanties van twee objecttypen, van het bestaande object naar het SOR object.

Deze linkset kan onderdeel zijn van dezelfde dataset die je wilt koppelen aan de SOR, maar kan ook een losse dataset zijn met verschillend beheer.

koppelen-relateren-linkset
Figuur 18 Relatie met SOR object meegemodelleerd in (externe) apart beheerde "linkset"

Ook hier maken we gebruik van objectstructuur plus identificatie om informatie "over elkaar heen te leggen" en in samenhang te presenteren.

Noot

Implicaties:

  • De SOR en je eigen objecten worden niet geraakt, op geen enkele manier, maar er is wel een relatie gelegd.
  • Je kan de historie van de relatie los beheren.
  • De link en het bestaande object hebben elk eigen historie.
7.2.2.2 Optie 2: Apart beheerde koppelinstanties

Een andere optie is het definieren van een nieuw objecttype, die de koppeling vertegenwoordig tussen objecten van objecttype A uit bron A en objecttype S uit de SOR. We noemen dit een koppelklasse. Een Koppelklasse is een speciaal construct waarmee twee objecttypes aan elkaar gekoppeld kunnen worden met uitgaande relatiesoorten vanuit de Koppelklasse naar de Objecttypes die met elkaar gekoppeld worden. Semantisch gezien is dit gelijk aan het relateren van twee objecten.

Bv. het objecttype AS-koppeling. Koppelingen komen te liggen tussen individuele objecten/instanties van A en individuele objecten/instantie van S, door middel van AS-objecten, die verwijzingen hebben naar A en S. Bv. een koppeling AS1 tussen A1 en S1 of AS2 tussen A21 en S35 enz.

Het beheer van de koppeling zit dan in principe op het niveau van de koppelklasse.

Noot
Noot
koppelen-relateren-koppelklasse
Figuur 19 Relatie met SOR object als instantie van een koppelklasse in (externe) dataset

Implicaties:

  • De SOR en je eigen objecten worden niet geraakt, op geen enkele manier, maar er is wel een koppeling.
  • Je kan de historie van de koppeling los beheren.
  • Je moet afleidingsregels specificeren om de semantische relatie tussen de gekoppelde objecten te manifesteren.

7.2.3 Uitbreiden van een bestaand objecttype

Voorwaarde:

  • Dit kan alleen als je eigen objecttype echt overeenkomt met wat er in de SOR onder een Gebouw wordt verstaan. Als dat zo is dan is dit semantisch direct goed geregeld.
  • In de implementatie zal het, vanwege het bijhouden van historie, nodig zijn om in je eigen object historie bij te houden op dezelfde manier als de SOR dit doet.
7.2.3.1 Optie 1: Specialiseer het SOR object en gebruik dezelfde identificatie

Hier breiden we een SOR objecttype in een externe dataset uit door deze op informatiemodelniveau te specialiseren en op instantieniveau gebruik te maken van de SOR identificatie voor identificeren van het object waarvoor we de gespecialiseerd beschrijving opnemen.

Noot
koppelen-uitbreiden-specialiseren
Figuur 20 Specialiseer het SOR object in (externe) dataset en gebruik de SOR identificatie

Implicaties:

  • Het is direct duidelijk dat alle definities en afbakeningen van de SOR ook gelden voor de extensie (de specialisatie is je eigen object, het SOR Gebouw is de generalisatie).
  • Hergebruik van de identificatie maakt het gemakkelijk om de externe (uitbreiding van ) gegevens te combineren met de SOR gegevens.
7.2.3.2 Optie 2: Stel het externe object gelijk aan het SOR object met een speciale relatie: isGelijkAan

Het is niet altijd mogelijk om dezelfde identificatie als de SOR te gebruiken. Mogelijk bestaat er al een andere identificatie in de externe registratie die ook waarde heeft buiten de context van de SOR. Deze optie introduceert een speciale relatie isGelijkAan, waarmee objecten aan elkaar gelijkgesteld kunnen worden. Binnen het SOR stelsel zou met deze speciale relatie kunnen bepalen dat twee verschillende identificatie platgeslagen kunnen worden tot 1 om zo de objectinformatie te kunnen combineren.

Noot
koppelen-uitbreiden-gelijkstellen
Figuur 21 Gebruik eigen identificatie voor (extern) object en stel dat object gelijk aan SOR object

Implicaties:

7.3 Aanbeveling

Voor de aanbevelingen wordt verwezen naar paragraaf Aanbevelingen met betrekking tot koppelen.

8. IMSOR Gebouw

De gegevenscatalogus van het tijdens de High-5 geproduceerde IMSOR Gebouw informatiemodel, inclusief diagram(men), is hier te vinden:

9. Vertalingsregels en afleidingsregels

9.1 Inleiding

Om te komen tot een samenhangend Gebouw in de SOR, moet data gecombineerd worden uit de BAG, BGT, WOZ en BRT. Om te weten welke data hoe gecombineerd moet worden, is een informatieanalyse nodig en veel kennis van de huidige basisregistraties. Op basis van deze informatieanalyse moeten vertaalregels gespecificeerd worden. De vertaalregels kunnen vervolgens worden gebruikt in de omzetting van data uit de huidige basisregistraties naar de SOR. In een slimme architectuur kunnen deze regels een plek krijgen in de 'semantische laag' die ervoor zorgt dat de data uit de huidige basisregistraties in samenhang kunnen worden benaderd. De vertaalregels vertellen dan precies hoe de data uit de basisregistraties moeten worden omgezet naar data conform het IMSOR model.

Tijdens deze High-5 hebben we een eerste (zeer kleinschalig!) begin gemaakt met het opstellen van zulke vertaalspecificaties, vooral om te beproeven waar we bij dit werk allemaal tegenaan lopen.

We hebben voor de SOR objecttypen Gebouw, Gebouwzone en Gebouwlaag een eerste aanzet tot een mapping gemaakt. Hierbij bleek dat je in zo'n mapping twee soorten gevallen tegenkomt:

Voor het realiseren van een semantische laag bovenop huidige registraties (volgens het model van de SOR) zijn dus vertalingsregels en afleidingsregels nodig. Deze willen we vastleggen op conceptueel niveau, zodat ze onafhankelijk zijn van een specifieke technische omgeving en (met hulp van de informatiemodelleur) zowel door domeinexperts als door programmeurs begrepen kunnen worden.

Vertalingsregels geven aan hoe de gegevens uit verschillende bronnen zich laten vertalen in gegevens conform het model van de SOR. Deze regels kunnen gericht zijn op de specifieke registraties in het kader van de SOR, waarbij mappings worden toegepast gebaseerd op transponeringstabellen. Echter is het ook wenselijk om deze regels zodanig op te stellen dat ze generiek genoeg zijn voor hergebruik buiten de context van de basisregistraties. Dit zou waardevol zijn voor de aansluiting met sectorale registraties; het gaat dan over breed toepasbare modelleerpatronen.

Afleidingsregels zijn nodig om uniformiteit te waarborgen. In gevallen waar het belangrijk is om afgeleide informatie vast te leggen in de SOR, dient deze afleiding op gestructureerde wijze te worden vastgelegd. Hiermee kunnen interpretatieverschillen in de inwinning/vastlegging van gegevens worden vermeden.

Afleidingsregels hebben betrekking op datgene wat momenteel niet expliciet in de registraties is opgenomen, maar wel van belang is voor de SOR. In principe zullen er geen afleidingsregels worden gespecificeerd voor bestaande registratiegegevens die momenteel worden afgeleid uit andere registraties. Echter is het wel belangrijk deze gevallen in kaart te brengen, zodat in een latere fase kan worden gekeken naar automatische afleiding vanuit de SOR.

9.2 Verschillende soorten vertalingsregels

Vertalingsregels kunnen eenvoudige één op één mappings zijn, maar ook complexe omzettingen. Toen we keken naar de mappings vanuit BAG, BGT en WOZ naar SOR Gebouw kwamen we op vertalingsregels die van zeer eenvoudig to zeer complex gingen. In deze paragraaf geven we een overzicht van de varianten.

Vertalingsregels kunnen betrekking hebben op vertalingen tussen de volgende elementen:

In basisregistratie In SOR Voorbeeld
waardelijst waarde waardelijst waarde Simpel geval: BRT-Gebouw.typeGebouw Toren = SOR-Gebouw.type Toren. Het komt ook voor dat de waarde in de bronregistratie een nauwer begrip lijkt te zijn van een waarde in de SOR, bijvoorbeeld: BRT-Gebouw.typeGebouw Boortoren < (specifieker dan) SOR-Gebouw.type Toren*. Soms lijkt er een relatie te zijn tussen de waardes van lijsten die behoren tot verschillende objecttypes. In deze gevallen is extra aandacht nodig voor het mappen en afleiden van attributen/relaties.
objecttype objecttype BAG Pand = SOR Gebouw
attribuutsoort waarde attribuutsoort waarde BAG-Pand.oorspronkelijk bouwjaar <waarde> = SOR-Gebouw.oorsponkelijk bouwjaar <waarde>
waardelijst waarde objecttype BGT-BegroeidTerreindeel.fysiekvoorkomen heide = SOR-Heide.
objecttype waardelijst waarde nog niet gevonden
waardelijst waarde attribuutsoort waarde nog niet gevonden
attribuutsoort waarde waardelijst waarde WOZ-object.aanduiding_repeterend ja = SOR-Gebouw.aard repeterend
objecttype attribuutsoort waarde nog niet gevonden
attribuutsoort waarde objecttype WOZ bouwlaag attribuut met getalswaarde wordt in SOR objecttype Bouwlaag met eigen 2.5D geometrie. NB hierbij moet de geometrie afgeleid worden.
Noot

10. Inventarisatie van manieren om vertaalspecificaties vast te leggen

Zoals in het vorige hoofdstuk is uitgelegd, zijn er in de SOR vertalingsregels en afleidingsregels nodig die uitdrukken hoe de SOR inhoud zich verhoudt tot de gegevens in de bestaande basisregistraties. Deze regels willen we vastleggen op conceptueel niveau, zodat ze onafhankelijk zijn van een specifieke technische omgeving en zowel door domeinexperts als door programmeurs begrepen kunnen worden.

Hiervoor hadden we niet direct een uitdrukkingsvorm voorhanden. Meestal worden vertaalspecificaties, vaak transformaties genoemd, in een technische omgeving uitgedrukt. Soms gebeurt dit op basis van vertaal- of 'mapping'-tabellen; deze hebben een niet-formeel karakter en complexere regels zijn er moeilijk in uit te drukken. We hebben tijdens de High-5 een korte inventarisatieronde gedaan van mogelijke uitdrukkingsvormen voor vertaalspecificaties.

10.1 INSPIRE harmonisatiemethode

Bij het harmoniseren van eigen data naar INSPIRE geharmoniseerde data moet veel data getransformeerd worden uit bronsystemen naar het INSPIRE datamodel.

Vaak wordt hier de tool HALE studio voor gebruikt. Hierin kun je vertaalspecificaties voor gegevens uitdrukken. Hoe dit precies eruit ziet en of je deze vertaalspecificaties ook kunt hergebruiken buiten de HALE omgeving weten we nog niet.

In het programma Basisregistratie Ondergrond (BRO) zijn vertaalspecificaties gemaakt van bron naar INSPIRE in Excel tabellen. Zie voorbeeld.

10.2 Niet-formele vertaaltabel

In het IGO project zijn vertaalspecificaties opgenomen in een vertaaltabel die kon worden gebruikt om samen met domeinexperts (die de inhoud kenden) vast te leggen hoe gegevens moesten worden gemapt of afgeleid. Daarna zijn deze specificaties in SPARQL construct statements geïmplementeerd.

Ook in het programma Basisregistratie Ondergrond (BRO) zijn vertaalspecificaties vastgelegd in een vertaaltabel (zie onder INSPIRE harmonisatiemethode).

10.3 Visuele mapping tools

Er bestaan ook visuele mapping tools. Binnen het IGO traject werd bijvoorbeeld de tool Weaver gebruikt. Zie voorbeeld.

In de context van XML transformatie zijn er visuele mapping tools op de markt, waaruit XSLT gegenereerd kan worden voor de technische transformatie; zie bijvoorbeeld Stylus Studio. Er is echter nooit een visuele uitdrukkingsvorm gestandaardiseerd. Deze visuele mapping tools hebben dezelfde beperking als mapping tabellen: complexere mappings zijn niet altijd goed te visualiseren.

10.4 UML

UML heeft voor zover wij konden ontdekken geen mogelijkheid om vertaalspecificaties uit te drukken in modelvorm. Hierbij plaatsen we de kanttekening dat UML zeer uitgebreid is, waardoor het kan zijn dat er wel een mogelijkheid bestaat die wij over het hoofd zagen.

UML biedt wel in klasse-diagrammen een mogelijkheid om aan te geven dat een property van een class derived is. Maar meer dan een aanduiding is dit niet; je kunt niet aangeven hoe de property zich verhoudt tot datgene waaruit hij is afgeleid.

Imvertor gebruikt wel een soort mapping relaties tussen conceptuele en logische modellen: tracing. Of dit geschikt is voor onze doeleinden hebben we niet kunnen bepalen.

10.5 QVT

Query/View/Transformation (QVT) is een aan UML gerelateerde standaard voor model transformaties. Ons is geen bestaande toepassing hievan bekend, maar vanwege de nauwe relatie met UML is het de moeite waard om ons hier verder in te verdiepen. Tijdens de High-5 hebben we dat nog niet gedaan.

10.6 XSLT

XSLT is een bekende declaratatieve transformatietaal waarin je kunt uitdrukken wat de transformatieregels zijn om van een bronformaat naar een doelformaat te komen. Het declaratieve karakter maakt de taal interessant; dit betekent dat de transformatieregels niet uitdrukken HOE een computer de vertaling van bron naar doel moet uitvoeren, maar alleen WAT de relatie is tussen bron en gewenste doel.

XSLT is echter een uitdrukkingsvorm op technisch implementatie-niveau (het zijn scripts; niet te lezen voor een domeinexpert) en werkt alleen met XML input. Daardoor is het voor ons doel niet geschikt.

10.7 PROV

Met PROV ([PROV-DM] en [PROV-O]) kun je vastleggen hoe gegevens van elkaar zijn afgeleid. Dit is vergelijkbaar met hoe je dat doet voor informatieobjecten.

Voor het vastleggen van de herkomst van een gegeven, moeten we het gegeven als PROV Entiteit modelleren. Dit betekent dat we een individueel gegeven als object moeten kunnen beschrijven, zodat we deze kunnen voorzien van extra eigenschappen. Hoe je dit het beste kunt doen moet verder onderzocht worden.

10.8 SHACL Rules

Met SHACL Rules ([SHACL-AF]) is het mogelijk om op basis van "shapes" in bestaande in RDF uitgedrukte gegevens, in combinatie met generatieregels, nieuwe gegevens af te leiden.

10.9 GraphQL

In GraphQL specificeer je een standaardschema, dat de brondata beschrijft, en een doelschema, dat beschrijft wat je terug wilt krijgen. Deze druk je uit in GraphQL queries. Net als bij XSLT heeft GraphQL een declaratief karakter.

Net als XSLT is GraphQL een taal op technisch implementatie-niveau, maar het abstraheert wel van verschillende soorten datastores. Daarom vinden we het interessant om te verkennen in de volgende High-5.

10.10 RML

Met RML (RDF Mapping Languague) kun je willekeurige gestructureerde data transformeren naar een doelmodel in RDF. De ingrediënten voor een mapping zijn:

Een vergelijkbare mapping-opzet zou ook toegepast kunnen worden voor het transponeren van gegevens. Hiervoor zouden bouwblokken uit RML hergebruikt kunnen worden. RML heeft bijvoorbeeld een rijke mogelijkheid om transformatiefuncties mee te nemen in een mapping op een declaratieve manier.

11. Gebouwen van bron naar SOR

11.1 Benodigde BAG en BGT objecten

In scope voor deze High5 zijn de SOR objecttypen uit [EMSO] paragraaf 5.3, voor zover deze te vormen zijn uit alleen BAG en BGT data. Bovendien is het objecttype Installatie in scope vanwege de beoogde koppeling met energiegegevens. De lijst met gebruikte SOR objecttypen is:

Niet in scope uit EMSO paragraaf 5.3:

De volgende objecttypen uit de BAG en BGT zijn nodig voor de transponering van bron naar deze SOR objecttypen:

BAG:

BGT:

11.2 Vertaalspecificatie

In het [EMSO] document, dat de inhoudelijke eisen aan de SOR beschrijft, is geen sprake meer van 'panden'; in plaats daarvan wordt het objecttype Gebouw geïntroduceerd. Meeste BAG/BGT panden kunnen één op één worden omgezet naar SOR Gebouw. In een aantal gevallen zullen BAG/BGT panden worden omgezet naar SOR Open bouwwerken. Daarnaast kan een aantal typen BGT OverigBouwwerk gemapt worden naar SOR Gebouw(typen Bunker of Schuur) en naar SOR Open bouwwerk (typen Open loods of Overkapping). Andere typen BGT OverigBouwwerk zijn ook weer terug te vinden in SOR Installatie.

Het volledige overzicht van de verhouding tussen deze objecttypen en eigenschappen in de bronregistraties en de SOR is beschreven in de mapping van Gebouw en Verblijfsobject (excel).

11.3 Eerste verkenning van de vertaalspecificatie

De hieronder volgende tekst en tabellen zijn eerdere versies van de vertaalspecificaties. Ze zijn opgenomen omdat de bij de verkenning opgetekende overwegingen relevant kunnen zijn. Kijk voor de meest recente inzichten in de mapping van Gebouw en Verblijfsobject (excel).

In een eerdere fase, voordat de scope voor deze High5 was vastgesteld, is een eerste analyse uitgevoerd van de vertaling van objecten uit BGT, BRT, BAG en WOZ naar SOR. Hierbij is vooral gekeken naar de SOR objecttypen Gebouw en Gebouwzone. Hoewel het hier niet om een complete vertaalspecificatie gaat, wordt de vertaling naar deze objecttypes wel in hoofdlijnen beschreven voor elk eigenschap opgenomen in de SOR. Hierbij is ook rekening gehouden met gegevens die mogelijk afkomstig zijn uit andere registraties (zoals de BRT of WOZ). De analyse wordt hieronder gepresenteerd, in de vorm van tabellen.

Een van de hoofdconclusies was dat de relatie tussen de typering van gebouwen in de SOR en de gebruiksdoelen, functies en typen van gebouwen in de BAG, WOZ en de BRT complex blijkt te zijn. Dat betekent ook dat het mogelijk nog heel lastig wordt om de geharmoniseerde SOR gebouwen, met name wat betreft de WOZ data, te vormen op basis van de huidige basisregistraties. In ieder geval is voor het maken van de juiste vertaalspecificaties veel inhoudelijke kennis van het WOZ informatiemodel en de WOZ data nodig.

11.3.1 Vertaling naar SOR-Gebouw

Gegeven in SOR Herkomst Transponering
Identificatie BAG en BGT BAG pand identificatie én BGT Pand identificatie overnemen, of BGT OverigBouwwerk identificatie wanneer SOR-Gebouw getypeerd wordt als vestingsgebouw, bijgebouw of schuur.
Geometrie BAG en BGT In het geval dat het SOR gebouw niet een vestingsgebouw (Bunker) of bijgebouw (Schuur) is, zullen er in principe twee geometrieën aanwezig zijn: omtrekgeometrie van de BAG en grondvlakgeometrie van de BGT. Beide nemen we over bij het gebouw. Wanneer het wel om één van de eerder genoemde typeringen gaat, zal er alleen een BGT geometrie aanwezig zijn en nemen we die over.
Type Nieuw / BRT / WOZ Dit is een nieuw attribuut. De 'hoofdtyperingen' die hier worden geïntroduceerd zijn niet aanwezig in de huidige modellen, met uitzondering van Toren (BRT) Schuur en Bunker (BGT). Alle nadere typeringen in de waardelijst lijken zowel uit de BRT als uit de WOZ te kunnen komen. De exacte herkomst is dus onduidelijk. Vaak is het 1:1 overgenomen (waarbij het om soortgelijke begrippen kan gaan, maar ook nadere typeringen - zie ook de lijst met voorbeelden van vertalingsregels), soms zijn de termen/begrippen anders beschreven - om deze reden is het belangrijk na te gaan in hoeverre deze termen en begrippen daadwerkelijk overeenkomen in betekenis (en in de data). Hiervoor is nadere analyse nodig en gedetailleerde kennis van de inhoud.
Aard Nieuw / WOZ Het attribuut zelf is nieuw ten opzichte van de registraties, de waardes niet. Voor Repeterend heeft de WOZ een attribuut aanduiding repeterend. De transponering voor de waardes Heterogeen en Vrijstaand is minder expliciet. Vrijstaand komt vaak terug in de typeringen van SOR Verblijfsobjecten (de waardes in deze lijst, waar vrijstaand in voorkomt, zijn afkomstig van de waardelijst Type voor WOZ-objecten). Het is dus mogelijk een gegeven dat moet worden afgeleid. De herkomst van Heterogeen is onduidelijk.
Oorspronkelijk bouwjaar BAG Direct uit de BAG te halen, bij bouwjaar. Let wel op dat WOZ Deelobjecten (vaak SOR Gebouwzones) ook een bouwjaar bevatten. In principe zou het oudste bouwjaar binnen Deelobjecten overeen moeten komen met het BAG bouwjaar. Wanneer dit niet het geval is, kan er sprake zijn van incorrecte data.
Naam BRT De naam van een SOR Gebouw is alleen aanwezig wanneer deze in de BRT bestaat. Aangezien de mapping tussen BRT en BAG/BGT - voor gebouwen - niet vanzelfsprekend is, eist de mapping van deze eigenschap meer aandacht.
Status BAG en BGT De SOR definitie voor Bestaand omvat de huidige twee BAG-statussen Pand in gebruik en 'Pand in gebruik (niet ingemeten)'. En de definitie voor Afgevoerd omvat de huidige twee BAG-statussen Niet gerealiseerd pand en Pand ten onrechte opgevoerd. Alle andere statussen kunnen direct vanuit de BAG worden gemapt, met uitzondering van In sloop - dit is een nieuw begrip, waarbij nieuwe gegevens ingewonnen zullen moeten worden op een later stadium.
Relatie (vanuit bouwlaag): Bouwlaag ligt in Gebouw ? Nog niet aan toegekomen.
Relatie (vanuit gebouwcomponent): Gebouwcomponent hoort bij Gebouw - De relatie is in de brondata niet aanwezig, maar is met behulp van de geometrieën uit de BGT af te leiden (de gebouwcomponent zit immers aan het gebouw vast).
Relatie (vanuit toegangsdeur): Toegangsdeur hoort bij Gebouw ? Nog niet aan toegekomen.
Relatie (vanuit installatie): Installatie hoort bij Gebouw ? Nog niet aan toegekomen.

11.3.2 Vertaling naar SOR-Gebouwzone

Het SOR objecttype Gebouwzone is gebaseerd op het WOZ Deelobject. Op basis van de huidige WOZ kun je vermoedelijk wel voor een groot deel de SOR gebouwzones afleiden. Het WOZ deelobject kan in eenvoudige situaties een heel woonhuis zijn, maar er kunnen ook meerdere deelobjecten voor één huis zijn: bijvoorbeeld de woning zelf, een garage en een serre. De indeling in deelobjecten wordt gemaakt op basis van wat voor de waardebepaling van het object van belang is (bijvoorbeeld op basis van mate van isolatie), en niet puur op gegevens zoals het bouwjaar. De bronhouders doen veel marktanalyse en gebruiken hierbij bijvoorbeeld informatie uit verkoopplatforms zoals Funda. Daarnaast wordt de WOZ gevoed met informatie uit de BAG over wijzigingen aan objecten zoals verbouwingen.

Om een idee te krijgen van de data kunnen we kijken in het WOZ waardeloket. Hierin staan alleen de WOZ waarden per WOZ object, maar de contouren van WOZ deelobjecten zijn waar er een directe relatie met de BAG in de data zit, wel gevisualiseerd.

De onderstaande tabel beschrijft voor de gegevens die bij SOR Gebouwzone zijn gespecificeerd, of en hoe deze uit de brondata gehaald kan worden.

Gegeven in SOR Herkomst Transponering
Identificatie WOZ WOZ Deelobject heeft een eigenschap nummerWOZDeelObject die we kunnen overnemen. Dit nummer is uniek in combinatie met het bijbehorende WOZ objectnummer.
Geometrie BAG/BGT WOZ deelobjecten hebben in de WOZ geen geometrie (in theorie wel - zie geometrie, maar deze wordt niet ingewonnen). Wel zijn ze gekoppeld aan de BAG voor zover er een corresponderend BAG object is. Bijvoorbeeld de geometrie van een woonhuis en van een schuur kun je uit de BAG halen via het gekoppelde verblijfsobject of pand. Maar de geometrie van een tuin of bijvoorbeeld een zwembad, carport, paardenrijbak of agrarische grond niet. De geometrieën van dat soort objecten zitten (deels) in de BGT. Via BAG pand en BGT pand zou je misschien het bij een pand horende erf (tuin) en andere objecten (bordes, carport, luifel, ...) kunnen vinden op basis van geometrische nabijheid en/of in combinatie met het kadastraal perceel.
Geometrie afbakening ? Dit gegeven herkennen we niet. Het lijkt meer een gegeven te zijn voor de bijhouder van de WOZ, de bronhouder, maar niet een gegeven dat voor afnemers relevant is. Het zit niet in de huidige registratie. In een situatie waarin 1 deelobject correspondeert met 1 pand, zou je de BAG of BGT kunnen gebruiken. Vergelijk dan de BAG en BGT geometrie met elkaar: als de polygonen hetzelfde of bijna hetzelfde zijn is het betrouwbaar om uit één van beide het oppervlak te berekenen, anders moet je opletten want dan heeft het gebouw een niet rechttoe-rechtaan vorm.
Bouwlaagnummer WOZ 1 op 1 over te nemen uit WOZ deelobject bouwlaag. NB In de SOR een verplicht gegeven, maar in de WOZ alleen gevuld als de bouwlaag relevant is voor de waardebepaling.
Bouwjaar WOZ Opgenomen bij deelobject als ofwel bouwjaar (type gYear), ofwel bouwjaarklasse (vrij tekstveld). Toelichting: het WOZ deelobject bouwjaar kan hetzelfde zijn als het oorspronkelijk bouwjaar in de BAG, maar in de WOZ is de informatie over bouwjaar gedetailleerder: als er meerdere deelobjecten zijn, bijvoorbeeld een apart deelobject voor later aanbouwde delen van een pand, is voor elk van deze deelobjecten het daadwerkelijke bouwjaar opgenomen. Het oudste bouwjaar binnen een set deelobjecten zou overeen moeten komen met BAG oorspronkelijk bouwjaar, zo niet dan duidt dat op incorrecte data.
Type WOZ Dit is in WOZ de gebruikscode (ook wel 'deelobjectcode') - waarschijnlijk het typeWOZDeelObject. Hiervoor is een mapping nodig. Zie transponeringstabel.
Aard WOZ Kan waarschijnlijk 1 op 1 worden overgenomen, maar dit gegeven zien wij eigenlijk als iets dan vooral belang heeft voor de bronhouder, niet voor de afnemer.
Gebruiksoppervlakte WOZ WOZ deelobject oppervlakte in combinatie met codeBrutoNettoOppervlakte. Dit geeft aan dat de oppervlakte op verschillende manieren bepaald kan zijn. Als de oppervlakte de gebruiksoppervlakte is, kan die 1 op 1 worden overgenomen. Anders is wellicht een berekening mogelijk. Verder: bij deelobjecten zijnde een woning werd altijd de inhoud in plaats van het oppervlakte bijgehouden. Bij niet woningen was dit wel het oppervlakte. Momenteel zijn de bronhouders de inhoudsgegevens naar oppervlakte aan het omzetten. Aandachtspunt voor ons: Als we met WOZ data gaan experimenteren, moeten we een gemeente selecteren die de transitie van inhoud naar oppervlakte al hebben gemaakt voor woningen. En deze gemeente moet het oppervlak dan wel per deelobject hebben geregistreerd (er zijn ook gemeenten die het gehele oppervlakte bij het WOZ object opnemen).
Status WOZ Mapping: WOZ deelobject statusWOZDeelObject. Dit is/was in de WOZ als percentages uitgedrukt; zie Voortgangspercentages bouw. Het IMWOZ specificeert het gegeven statusWOZDeelObject met een waardelijst en op niveau WOZ-object de aanduiding in aanbouw. Beide zijn te transponeren, zie tabel hieronder.
Hoort bij vbo WOZ Mapping: WOZ deelobject bestaatUit of bestaatUitPand. Als het WOZ deelobject correspondeert met BAG objecten (verblijfsobject, standplaats, ligplaats of pand), dan is deze relatie in de brondata opgenomen. Niet alle gebouwzones corresponderen met een BAG object (denk aan tuin, zwembad, ...). Zo niet dan is het een type object dat niet in de BAG zit maar wellicht wel in de BGT. Zie verder de transponering bij het gegeven geometrie.
Ligt op bouwlaag WOZ Dit zit in de WOZ als eigenschap van WOZ deelobject, maar het is een apart object in de SOR met 2.5D geometrie, dus een vlak met voor elk coördinatenpaar een z waarde. Je kunt de geometrie bij gebouwen met eenvoudige vormen (als de BAG en BGT geometrie ongeveer hetzelfde zijn) van de BAG overnemen en dan aan de hand van bouwlaagnummer, bouwjaar en woningtype een hoogte erbij genereren. In het oppervlakte verdiepingsdocument voor gemeenten staat een tabel die kan worden toegepast om het volume van woningen, afhankelijk van hun type en bouwjaar, om te rekenen naar oppervlakte, waarbij per bouwjaarklasse een verdiepinghoogte wordt gehanteerd (zie hieronder). Dit zou je kunnen hanteren als z waarde voor bouwlagen van woningen.
bouwlaag verdiepingshoogtetabel
Figuur 22 Tabel met omrekenfactor woningvolume naar oppervlakte (bron)

Transponering van waardelijst status

De status (levenscyclus fase) van WOZ deelobjecten wordt bijgehouden als percentage, waarbij 0% betekent dat de bouw van een object in voorbereiding is, en 100% dat het een bestaand object is waarvan de bouw gereed is. De WOZ is niet geïnteresseerd in de voorfase (ontwerp, planning), alleen in gerealiseerde objecten; maar wel vanaf start bouw. Als de fundering van een gebouw ligt mag al 20% van de uiteindelijke waarde aangeslagen worden.

In het IMWOZ wordt echter ook een gegeven aanduiding in aanbouw gespecificeerd. Hoe zich dit precies verhoudt tot de status moet nog worden uitgezocht.

In de SOR kent de Gebouwzone een levenscyclus met statussen zoals gedefiniëerd voor alle functionele ruimten.

De globale transponeringstabel:

SOR status functionele ruimte transponering percentage transponering waardelijst
Ontwerp niet in WOZ niet in WOZ?
In voorbereiding WOZ deelobject met statuspercentage kleiner dan 100%, eventueel in combinatie met aanduiding in aanbouw 1 (gevormd, niet actief)
Bestaand WOZ deelobject met statuspercentage = 100% 0 (actief)
Onbruikbaar WOZ deelobject met staat van onderhoud = vervallen (dit zou erin moeten zitten, maar is mogelijk wel lastig af te leiden) 8 (beëindigd)
Opgeheven ? 8 (beëindigd)
Afgevoerd niet in WOZ (deze objecten komen naar verwachting nooit vanuit de BAG in de WOZ) 9 (ten onrechte opgevoerd)

12. Specificatie van de vertaling van historie

BAG, BGT en IM Gebouw volgen alle NEN3610:2011 of 2021 en NEN3610 komt overeen met de SOR.

We onderscheiden de tijdslijn Geldigheid, de tijdslijn Registratie bij de bronhouder en de tijdslijn Registratie bij de LV. Dit houden we bij per versie van een object.

Deze gegevens willen we voor BGT gegevens afleiden uit de BGT en voor de BAG uit de BAG. Onderstaand is de mapping beschreven.

In deze High-5 hebben we te maken met de LVBGT en de LVBAG. Dus beschikbaarOp mapped op de registratie tijd in de LV. Eigenlijk het tijdstip van beschikbaarstellen maar dat is in dit geval hetzelfde. De gebruiker stelt een vraag: geldigOp Tg en beschikbaarOp Tb en de API vertaalt dit request onder water naar het tijdstip registratie in de LV. Bij het opleveren van de data in de response worden de velden van de LV-en gemapped naar de velden van IM Gebouw.

12.1 Historie in IM Gebouw

IM Gebouw - registratie gegevens: in de definitie van tijdstipRegistratie en eindRegistratie van de versie van een object staat: “Tijdstip waarop deze versie van het informatieobject beschikbaar was via deze dienst.” - dit komt in dit geval overeen met tijdstip registratie in de LV.

Vanwege de vertaal specificatie van de BAG en BGT samen moet in IM Gebouw de beginGeldigheid en eindGeldigheid een date time zijn of een datatype keuze.

Vanwege de vertaalspecificatie van de BAG en BGT samen moet in IM Gebouw de tijdstipRegistratie en eindRegistratie een date time zijn.

Bij beide tijdslijnen is nog een leerpunt hoe we ermee omgaan dat de BAG werkt met date, BGT met date time.

12.2 Historie in BAG

IMBAG LV Toelichting IM Gebouw
begin geldigheid begin geldigheid in de BAG (datum) begin geldigheid
eind geldigheid eind geldigheid in de BAG (datum) begin geldigheid
tijdstip registratie tijdstip registratie in de BAG (datum tijd) Niet
eind registratie eind registratie in de BAG (datum tijd) Niet
tijdstip registratie LV tijdstip registratie in de LVBAG (datum tijd) tijdstip registratie
eind registratie LV eind registratie in de LVBAG (datum tijd) eind registratie

Beëindigde objecten: BAG heeft altijd een versie/voorkomen, ook als een object beëindigd is. Een voorkomen heeft dan een eindstatus, zie vertaal specificatie 'status' (en https://imbag.github.io/praktijkhandleiding/artikelen/wat-is-het-verschil-tussen-actieve-voorkomens-actuele-voorkomens-en-huidige-voorkomens )

Versies van objecten met bijzondere tijdstippen erin:

indicatieNietBAG: Dit is een LV veld om versies niet niet in de BAG voorkomen te verwijderen uit de LVBAG (logisch niet technisch). Dit veld zit (nog) niet in IM Gebouw.

Negeer deze versie als indicatieNietBAG gevuld is en beschikbaarOp >= indicatieNietBAG.

Map deze versie wel naar IM Gebouw als indicatieNietBAG leeg is, of als beschikbaarOp < indicatieNietBAG.

OF neem dit veld toch gewoon over naar IM Gebouw, door IM Gebouw uit te breiden in de API met dit veld. Dit lijkt eenvoudiger voor de High-5.

tijdstipInactief: Dit is een BAG veld. Dit veld zit (nog) niet in IM Gebouw.

Negeer deze versie als inactief gevuld is en beschikbaarOp >= inactief.

Map deze versie wel naar IM Gebouw als inactief leeg is, of als beschikbaarOp < inactief.

OF neem dit veld toch gewoon over naar IM Gebouw, door IM Gebouw uit te breiden in de API met dit veld. Dit lijkt eenvoudiger voor de High-5.

tijdstipInactiefLV: Dit is een LVBAG veld. Dit veld zit (nog) niet in IM Gebouw.

Negeer deze versie als inactiefLV gevuld is en beschikbaarOp >= inactiefLV.

Map deze versie wel naar IM Gebouw als inactiefLV leeg is, of als beschikbaarOp < inactiefLV.

OF neem dit veld toch gewoon over naar IM Gebouw, door IM Gebouw uit te breiden in de API met dit veld. Dit lijkt eenvoudiger voor de High-5.

12.3 Historie in BGT

BGT wint gegevens in op een bepaalde datum en op dat moment worden het object, in een verschijningsvorm, geconstateerd. De BGT registreert deze gegevens vervolgens.

De BGT kent de volgende gegevens:

IMBGT LV Toelichting IM Gebouw
tijdstip registratie tijdstip registratie in de BGT beginGeldigheid
eind registratie eind registratie in de BGT eindGeldigheid
publicatiedatum LV tijdstip registratie in de LVBGT tijdstip registratie
publicatiedatum LV zie vertaal specificatie iets verderop eind registratie

Beëindigde objecten: zie vertaalspecificatie iets verderop.

Versies van objecten met bijzondere tijdstippen erin: niet aanwezig.

Tijdslijn geldigheid

Gewenst gegeven: beginGeldigheid van een voorkomen van object.

Gewenst gegeven: eindGeldigheid van een voorkomen van object

Tijdslijn registratie bij LV (t.b.v. tijdreizen)

Gewenst gegeven: tijdstipRegistratie in LVBGT van een voorkomen van object

Gewenst gegeven: eindRegistratie in LVBGT van een voorkomen van object

Vertaal specificatie eindRegistratie

Elke versie van een object heeft in IM Gebouw een eind registratie (eind registratie in de LV).

Er is echter geen PublicatieDatumEind in de LVBGT, dus deze eindRegistratie kan je niet 1 op 1 mappen, maar moet je afleiden van het opvolgende objectversie en daarvan de LV-Publicatiedatum.

Als er een opvolgende versie bestaat: neem hiervan publicatiedatum LV en gebruik deze als eindRegistratie.

Als er geen opvolgende versie bestaat: dan is er toch wel een eindRegistratie. Zie vertaal specificatie van beeindigde objecten, die een nieuw opvolgende objectversie creëert (met een eindstatus). Het tijdstipRegistratie van dat opvolgende voorkomen is dat de eindRegistratie van deze versie.

Je kan kiezen: leid dit af tijdens bevraging, of registreer dit bij het inladen. We willen leren wat handiger is.

Vertaal specificatie beëindigde objecten

Als een object beëindigd is in de BGT dan is er na dit moment geen versie van het object meer. De BGT gebruikt hier geen nieuwe versie met een eindstatus, en dit is wel de bedoeling in IM Gebouw. In IM Gebouw is er dus wel een versie van het object, met een eindstatus. Deze extra versie met een eindstatus kan je niet mappen, maar moet je afleiden.

ALS een versie uit de BGT een gevulde objectEindtijd (8.1.2) heeft dan is deze versie de laatste versie uit de (LV)BGT.

Maak een nieuwe versie van het object, met:

Je kan kiezen: leid dit af tijdens bevraging, of registreer dit bij het inladen. We willen leren wat handiger is.

Tijdslijn registratie bij de bronhouder

Zit niet in de registratie gegevens van IM Gebouw, wanneer we IM Gebouw samenstellen vanuit de LVBGT.

Mogelijk komen deze gegevens wel in de API response om de controleren of de herleidbaarheid van de gegevens klopt.

Gewenst gegeven: tijdstipRegistratie Bronhouder van de versie van een object

Gewenst gegeven: eindRegistratie Bronhouder van een versie van een object

Als we deze gegevens wel opnemen in de API response, zet deze dan niet erbij in IM Gebouw zelf maar plaats deze erbuiten. Noem deze dan a.u.b. zoals de LVBGT ze levert, dit is BGT.tijdstipRegistratie en BGT.eindRegistratie en merk op dat de naam weliswaar overeenkomt met IM Gebouw.tijdstipRegistatie en IM Gebouw.eindRegistatie, maar de definitie en de data niet. IM Gebouw gebruikt immers de registratie tijdstippen in de LVBGT (publicatiedatum) als data voor IM Gebouw.tijdstipRegistratie en IM Gebouw.eindRegistratie.

13. Lessons Learned informatiemodellering

13.1 Inzichten: samenvatting

Deze High-5 heeft een aantal inzichten opgeleverd over informatiemodellering die hier worden samengevat:

  1. Om de geo-basisregistraties in samenhang te kunnen gebruiken, moeten we gegevens uit de huidige basisregistraties combineren. Dit lijkt vaak eenvoudiger dan het is. Zelfs wanneer dezelfde terminologie wordt gebruikt bij het specificeren van modelelementen, zijn er vaak nog subtiele verschillen in de definities hiervan. Begrippen zijn soms anders afgebakend – dit geldt dus ook voor data die hierop gebaseerd is. Om deze reden kunnen informatieobjecten/gegevens afkomstig van verschillende registraties niet zomaar over elkaar gelegd worden, ook al worden ze beschreven door dezelfde termen.
  2. Hoewel het samenvoegen van de registratiemodellen niet direct tot een samenhangend geheel zal leiden, kan hiernaartoe gewerkt worden middels een aantal modelleerprincipes. Deze principes vertalen zich in modelleerpatronen voor object centraal modelleren. Verschillende patronen kunnen worden toegepast om vanuit andere registraties naar de SOR te koppelen – hiermee wordt het een stuk gemakkelijker om objecten aan elkaar te relateren.
  3. We hebben vertaalspecificaties nodig op conceptueel niveau, zodat deze in verschillende technische talen kunnen worden uitgedrukt. Dit draagt bij aan de ontkoppeling tussen de duiding van gegevens en de ontsluiting van gegevens. Vertaling van de huidige bronnen naar de SOR zal op onderdelen lastig zijn.
  4. We moeten niet naar de SOR kijken als een volledig model, maar als een groeimodel. Hierbij is het belangrijk om korte en lange termijn doelen te stellen. Op de korte termijn is het streven naar een SOR MVP (minimal viable product) realistischer. Vanuit een inhoudelijk perspectief wordt in de SOR MVP vooral gekeken naar de samenhang van gegevens waarbij redelijk simpele vertalingsregels aan bod komen – dus geen complexere afleidingsregels. Ook is het belangrijk rekening te houden met huidige technologie. Door een SOR MVP in de praktijk te toetsen kunnen inzichten worden opgedaan die de standaardisatie van het volledige SOR model ten goede komen.
  5. Bij het opstellen van de vertalingsspecificaties voor historie en tijdslijn is onderkend dat bepaalde attributen buiten scope zijn voor de modellering van SOR informatieobjecten in de huidige fase. Hier kunnen verschillende redenen voor zijn, dit zal moeten worden gedocumenteerd en teruggekoppeld aan de relevante partijen. Als voorbeeld: het attribuut versie kan momenteel niet gemakkelijk dynamisch worden berekend. Daarnaast is het belangrijker om te weten wanneer gegevens geldig zijn, dan om welke versie het gaat. Daarom wordt dit attribuut voorlopig niet opgenomen.
  6. Met betrekking tot het koppelen van objecten uit andere informatiebronnen met objecten uit de SOR is er nog geen aanbeveling. Er wordt nog nagedacht over welke koppelmethode de voorkeur heeft van dit high-5 team.

13.1.1 SOR model en modelleerpatronen

Om beter te begrijpen hoe we naar een samenhangende registratie kunnen toewerken moeten we de huidige informatiemodellen erbij halen. Bij het samenvoegen van objecttypes uit de modellen wordt snel duidelijk dat er veel soorten gegevens door elkaar lopen. Een belangrijke principe in de context van deze high5 was dan ook: neem alleen directe eigenschappen op bij een bepaald objecttype. Om ervoor te zorgen dat deze principes op een stelselmatige manier worden toegepast zijn modelleerpatronen nodig. In de NEN3610 wordt een belangrijk patroon voor registratiegegevens gespecificeerd die deels invulling geeft aan dit principe. In deze high5 is daarnaast aandacht besteed aan drie andere patronen: voor brongegevens, voor de afleiding van informatieobjecten, en voor historie/tijdlijn. Voor het modelleren van brongegevens en de afleiding van informatieobjecten is PROV-O uitermate geschikt, deze kan worden toegepast in de SOR door het NEN3610 patroon voor registratiegegevens als aanknopingspunt aan te houden.

Uiteindelijk moet het mogelijk zijn om vanuit andere registraties naar de SOR toe te koppelen. Dit kan worden gerealiseerd door verschillende objecttypes aan elkaar te relateren, of door een bestaand SOR objecttype uit te breiden. Voor het relateren van objecttypes zijn er een aantal opties geïnventariseerd: je kunt objecttypes combineren in één SOR object, apart beheerde linksets genereren, of gebruik maken van een koppelklasse. Voor de laatste optie zijn extra documentatie of algoritmes nodig om te kunnen afleiden dat er een relatie bestaat tussen de objecten.

13.1.2 Van bron naar SOR

Om brongegevens te vertalen naar het model van de SOR is het van belang om naast modelleerpatronen ook vertaalspecificaties op te stellen. Deze specificaties bevatten voor de SOR zowel vertalingsregels als afleidingsregels. Vertalingsregels geven aan hoe gegevens uit de bronregistratie zich laten vertalen in gegevens conform de SOR; dit kunnen zowel simpele als complexere mappings zijn. Daarnaast zijn ook afleidingsregels nodig, wanneer gegevens niet expliciet aanwezig zijn in de bronregistratie maar wel kunnen worden afgeleid. Deze specificaties dienen op conceptueel niveau te worden vastgelegd, zodat ze onafhankelijk zijn van een specifieke technische omgeving. De regels moeten begrijpelijk zijn voor degenen die ze implementeren, maar ook voor domeinexperts die inzicht hebben in de achterliggende betekenis van de data.

Er zijn meerdere opties mogelijk voor de vastlegging van deze regels. Om een idee te krijgen over de soorten regels die aan de orde zijn voor de SOR is gekeken naar de transponering van Gebouw objecten uit de registraties. Samenhang met de WOZ blijkt lastiger. Dit heeft vooral te maken met verschillen in de typeringen van SOR gebouwen en WOZ objecten, waarbij ook veel inhoudelijke kennis nodig is. Er is ook een wens om geometrie af te leiden uit andere gegevens – of en hoe dergelijke afleidingsregels haalbaar zijn moet nog worden onderzocht.

13.1.3 SOR model in de praktijk

De SOR zou je vanuit de praktijk eerder als een groeimodel kunnen zien – een gradiënt oplossing die steeds verder wordt ontwikkeld en toegepast. Hierbij horen korte termijn en lange termijn doelen. Op de korte termijn zal de focus komen te liggen op de realisatie van een SOR MVP (minimal viable product) - een tussenoplossing totdat de SOR, stap voor stap, volledig kan worden ingevoerd. Vanuit een inhoudelijk perspectief zou in de SOR MVP de nadruk kunnen liggen op de samenhang van gegevens waarbij redelijk simpele relaties en vertalingsregels aan bod komen. In een later stadium kunnen complexere onderdelen, waarvan de meerwaarde duidelijk is, toegevoegd worden (waarbij bijvoorbeeld extra inwinning of kennis nodig is).

De opbouw van het SOR model heeft als voordeel dat er een ontkoppeling ontstaat tussen de duiding van gegevens en de ontsluiting van gegevens. Het resultaat is een implementatie-onafhankelijk model waarmee verschillende ontsluitingsvormen kunnen worden ondersteund. Dit is belangrijk omdat het ontwikkelaars in staat stelt verschillende technieken te combineren, zonder dat er verwarring ontstaat over de duiding van de gegevens.

In het IGO traject (Integrale Gebruiksoplossing) werden verschillende basisregistraties gemakkelijk toegankelijk gemaakt door gegevens uit de registraties samen te voegen. Echter is het bij de samenvoeging van geometrieën en objectgegevens niet altijd duidelijk wat de relatie tussen deze gegevens is. Hiervoor is de SOR nodig: om de juiste duiding van een object te kunnen ontsluiten.

13.1.4 Modelleerpatroon: historie en tijdlijn

Bij het integreren van historie- en tijdlijngegevens uit de huidige basisregistraties zijn een aantal uitdagingen geïdentificeerd. Ten eerste is gekeken naar de definities van tijdslijnen in de registraties, en of deze ook daadwerkelijk overeenkomen. Niet alle registraties kennen momenteel beide tijdslijnen die in de SOR worden behandeld. Om dit wel mogelijk te maken zijn vertalingsregels uitgewerkt.

Ook is in het kader van de historie rekening gehouden met de identificatie van objecten, aangezien er in sommige gevallen sprake is van meerdere identificaties. Voor de huidige fase van de SOR lijkt het vooralsnog voldoende om de identificaties van de onderliggende registraties over te nemen – voor de gebruiker levert dit geen problemen op. Een belangrijke punt was het in elkaar schuiven van objecten uit verschillende basisregistraties.

Voor tijdsreisvragen zijn twee insteken onderzocht: je kunt een tijdreis vraag aan elke basisregistratie stellen en het antwoord vervolgens samenvoegen, of het op basis van de geldige levenscycli doen. Beide insteken zijn realiseerbaar, waarbij de eerste optie eenvoudiger te implementeren is.

13.2 Aanbevelingen

13.2.1 Algemene aanbevelingen

13.2.1.1 Aanbeveling met betrekking tot gebouwen

Om te komen tot een geharmoniseerd / geconsolideerd Gebouw in de SOR, op basis van de huidige objecten in de basisregistraties, is nader onderzoek nodig. Alle BAG/BGT panden kunnen worden omgezet naar SOR Gebouw; dit geldt ook voor enkele typen BGT OverigBouwwerk. Maar de juiste WOZ data erbij vinden is lastiger. De relatie tussen de typering van gebouwen in de SOR en de gebruiksdoelen, functies, en typen van gebouwen in de BAG, WOZ en de BRT blijkt bovendien complex te zijn.

Aanbeveling: Begin met BAG + BGT harmonisatie. Voor het harmoniseren van WOZ gebouwdata in de SOR moet, indien dat binnen scope is, iemand met veel WOZ kennis bij de volgende high 5 aanwezig zijn om de vertaal- en afleidregels scherper te maken.

13.2.1.2 Aanbevelingen met betrekking tot koppelen

Er wordt nog nagedacht over welke optie of opties uit § 7.3 Aanbeveling, waarin een aantal koppelmethoden beschreven worden, de voorkeur heeft van dit high-5 team.

Voor afnemers is het van belang dat gegevens en modellering er hetzelfde uitziet, zodat afnemers het geheel ook ervaren als een samenhangend stelsel. Dit wordt voor de SOR gestandaardiseerd, maar voor andere bronnen nog niet.

Om standaardisatie t.b.v. afnemers goed voor elkaar te krijgen zouden we kunnen denken aan aansluitvoorwaarden. Bij aansluitvoorwaarden kan je er bijvoorbeeld aan denken dat de SOR en andere bronnen aan dezelfde standaarden voldoen wat betreft:

  • Modellering;
  • Identificatie;
  • Historie (ontsluiten) en tijdreizen;
  • Andere standaarden die nodig zijn om te komen tot een samenhangend stelsel van gegevens uit basisregistraties en niet-basisregistraties.

Het is nog wel de vraag of dergelijke aansluitvoorwaarden afgesproken kunnen worden.

13.2.2 Aanbevelingen voor het vervolg van de High-5

13.2.2.1 Aanbevelingen met betrekking tot historie
  1. Inhoud geeft aan dat een geldige levenscyclus samenstellen inderdaad een vraag is die we moeten kunnen beantwoorden. Zie hoofdstuk Historie - insteek B (onderin).

  2. De implementatie maakt gebruik van een vertaalspecificatie om historie uit verschillende bronnen in elkaar te schuiven.

  • Gebruik insteek A voor tijdreis vragen op een SOR Gebouw conform de NL API strategie.
  • Gebruik insteek B om de voor geldige levenscyclus van een SOR Gebouw te kunnen leveren. Gebruik niet insteek B om vervolgens de tijdreisvraag te beantwoorden, want deze laaste insteek is een stuk minder efficiënt. Het is nuttig om te testen of beide routes dezelfde antwoorden geven, om te bewijzen dat de implemenaties kloppen.

ACTIE: vertaalspecficatie van A en B laten reviewen door team van 2e high-5.

  1. Elke geo-basisregistratie levert een API voor tijdreizen (t.b.v. insteek A) en een API om een geldige levenscyclus mee op te vragen (t.b.v. insteek B).

ACTIE --> uitzetten bij Landelijke Voorziening of basisregistratie.

14. Benodigdheden ten behoeve van API's

Dit hoofdstuk beschrijft een opsomming van de benodigdheden om API's te maken voor afnemers/gebruikers, met name voor developers.

We onderscheiden voor de High-5's de volgende externe API's:

14.1 Overzicht input voor externe API's

De input die hiervoor gebruikt kan worden:

  1. Informatiemodel in ReSpec (html), te vinden in § 8. IMSOR Gebouw.
  2. Informatiemodel in een mim-export formaat (in wording, nog niet officieel), in XML.
  3. Informatiemodel in een RDF formaat (RDFS/OWL/SHACL)
  4. YAML/JSON schema van het informatiemodel

14.2 Interne API's

Verder is er een integratiecomponent voorzien die de data uit de BAG en de BGT samenvoegt volgens vertaalregels. Deze integratiecomponent kan vervolgens gebruikt worden om de genoemde 4 externe API's te voeden.

We willen vooral leren hoe dit werkt, of dit werkt, wat dit betekent voor API specificaties en wat de benodigde input hiervoor is.

Deze component heeft nodig:

Hiervan wordt een GraphQL schema gemaakt t.b.v. een (interne) API.

14.3 Gebruik van de interne API door de externe API's

De interne GraphQL API kan gebruikt worden voor de hierboven genoemde API's 1, 2, 3 en 4.

Vraag: hoe precies de GraphQL gebruikt kan worden t.b.v. API 1 t/m 4 is een onderdeel van de 'implementatie' High-5.

Vraag: voor de LD API, gebruiken we dan de interne GraphQL API of gebruiken we daarvoor de database die onder iGO ligt (voor de High-5).

15. Implementatiefase

Dit hoofdstuk bevat de beschrijving van de opzet, resultaten en inzichten van de laatste experimenteersessie uit deze High-5 reeks, de implementatiedagen van januari 2022.

Het gaat bij deze implementatie om een verkenning om te ervaren hoeveel (of hoe weinig) er van de SOR gerealiseerd kan worden vanuit de huidige registraties. Het is geen ontwikkeling maar onderzoek.

15.1 Onderzoeksvragen

In deze fase implementeren we het gemaakte SOR Gebouw MVP model en de transponeringsregels. We willen de volgende vragen beantwoorden:

15.2 Opzet

Architectuur van de implementatie
Figuur 23 Architectuur van de implementatie

De onderste laag van deze architectuur, ontsluiting bij de bron, is in de voorbereiding al gerealiseerd door het Kadaster. In deze High-5 realiseren we de bovenste laag, Services, met daarin afnamevoorzieningen voor verschillende doelgroepen:

Als proefgebied is voor Swifterbant (gemeente Dronten) gekozen.

15.3 Scope beperking

We zijn in de implementatiefase begonnen met een hele bescheiden scope met daarin alleen het objecttype Gebouw. Op dag 2 hebben we Open Bouwwerk hieraan toegevoegd en op dag 3 Gebouwcomponent.

Aan Verblijfsobject en Installatie zijn we niet toe gekomen.

15.4 Resultaten

De implementatie-onderdelen zijn gerealiseerd in een ontwikkelomgeving van het Kadaster en helaas niet publiek beschikbaar.

15.4.1 Orchestratielaag en Lookup API SOR

De orchestratielaag is het intelligente hart van de architectuur: wat we aan het begin van deze High-5 serie de 'semantische laag' noemden. De orchestratielaag regelt de aggregatie van één of meerdere onderliggende services. Deze services kunnen fysiek bij verschillende organisaties worden gehost zodat een federatief systeem mogelijk is. Als gebruiker van de Lookup API hoef je geen kennis te hebben van de onderliggende systemen, in dit geval de BAG en de BGT.

De Lookup API is onderdeel van deze orchestratielaag en zorgt voor ontkoppeling tussen onderliggende systemen en de uiteindelijke raadpleegvoorzieningen. Het resultaat van een zoekvraag door een gebruiker wordt door deze Lookup API samengevoegd uit antwoorden van de onderliggende systemen en met behulp van de transponeringsregels gemapped naar het IMSOR model.

Deze architectuur met transponering en orchestratie in het hart resulteert in een “virtuele” basisregistratie. Alles gebeurt on the fly, er is geen tussentijdse opslag.

De Lookup API heeft een [GraphQL] interface. Dit is een goed passende API stijl voor orchestratie, omdat het anders dan een gewone REST API, die een soort veelgestelde vragen voorziening is, een hoge mate van flexibiliteit biedt voor afnemers. Je kan zelf je vragen samenstellen en bepalen welke gegevens je in het resultaat wilt hebben. Ook is het mogelijk om delen van zoekvragen parallel te verwerken.

GraphQL screenshot
Figuur 24 GraphQL query en resultaat

15.4.2 Transponeringsregels

De transponeringsregels die zijn opgesteld door inhoudelijke experts in de eerste en tweede High-5 sessie, zijn in de implementatiefase omgezet naar machineleesbare regels. Ze beschrijven de vertaling van brondatamodellen naar het doelmodel: het model van het samenhangende SOR gebouw. Deze transponeringsregels moet je zien als een soort configuratie. De Lookup API is intelligent genoeg om deze regels te lezen, interpreteren en uitvoeren. De semantiek is zo gescheiden van de orchestratieprogrammatuur.

De transponering is voor Gebouw, Open Bouwwerk, en Gebouw component gerealiseerd. Voor de meeste attributen van deze objecttypen is een regel opgesteld die beschrijft waarmee het moet worden gevuld uit de bronregistraties. Een aantal attributen is om verschillende redenen niet getransponeerd. Het overzicht staat hieronder.

Het attribuut status dat in alle objecten voorkomt was een uitdaging om te transponeren. De SOR heeft een nieuwe onderverdeling van levenscycli. Met behulp van het SOR begrippenkader hebben we de SOR levenscyclus slim op de BAG en BGT status kunnen mappen.

De transponeringsregels zijn in deze fase als onderdeel van de LookUP API gerealiseerd ...

Transponeringsregelsarch1
Figuur 25 Transponeringsregels als onderdeel van de Lookup API

... maar moeten uiteindelijk een apart onderdeel worden in de orchestratielaag.

Transponeringsregelsarch2
Figuur 26 Transponeringsregels gepositioneerd in de orchestratielaag

Een algemene vraag die tijdens deze High-5 nog niet uitgebreid aan de orde is geweest, is hoe kunnen we verifiëren of de vertaalregels correct zijn geïmplementeerd? Daarnaast zijn er altijd gedetailleerde transponeringsvraagstukken waar een oplossing voor gevonden moet worden. Een voorbeeld is Wat als de bronhouder code van een BGT (pand) object niet hetzelfde is als die van het corresponderende BAG object? Dit is een kwaliteitsissue dat bij de transponering mogelijk aan het licht zou kunnen komen en waar een oplossingsrichting voor gekozen moet worden.

15.4.2.1 Gebouw transponering

Er zijn transponeringsregels geschreven waarmee alle BAG Pand objecten worden getransponeerd naar SOR Gebouw. Enkele attributen van BGT Pand worden erbij gezocht. BGT OVerigBouwwerk met type = Schuur of Bunker worden ook getransponeerd naar SOR Gebouw.

Attribuut Realisatie Toelichting
domein Standaard vulling
identificatie Uit BAG indien mogelijk, anders uit BGT
type Deels geïmplementeerd vanwege scope. Veel typen moeten uit BRT of WOZ komen. Bij alle BAG panden is nil ingevuld. Bij overig bouwwerken uit de BGT is het type, Schuur of Bunker daarvandaan overgenomen.
aard Buiten scope: BRT/WOZ
geometrie omtrek Uit BAG
geometrie grondvlak Uit BGT
naam Buiten scope: BRT
oorspronkelijkBouwjaar Uit BAG
relatieveHoogteligging Uit BGT. Niet in EMSO aangemerkt als inhoud SOR, maar voor deze beproeving wel interessant om mee te nemen. Zolang we geen 3D hebben...
status Uit BAG/BGT
15.4.2.2 Open Bouwwerk transponering

Dit objecttype komt uit de BGT en wordt als het gaat om een OverigBouwwwerk met attribuut type = Open loods of Overkapping getransponeerd naar SOR Gebouw.

Attribuut Realisatie Toelichting
domein Standaard vulling
identificatie Uit BGT
type Uit BGT
geometrie Uit BGT
isOnderdeelVan geen mapping gespecificeerd. Dit gegeven zit niet in de brondata, er moet een afleidingsregel voor gemaakt worden.
relatieveHoogteligging Uit BGT. Niet in EMSO aangemerkt als inhoud SOR, maar voor deze beproeving wel interessant om mee te nemen. Zolang we geen 3D hebben...
status Uit BGT
15.4.2.3 Gebouwcomponent transponering

De volgende objecten worden getransponeerd naar SOR Gebouwcomponent:

  • Alle BGT Gebouwinstallatie objecten met attribuut type = Bordes, Luifel, of Toegangstrap.
  • Alle BGT Kunstwerkdeel objecten met attribuut type = Perron worden getransponeerd naar Gebouwcomponent.
Attribuut Realisatie Toelichting
domein Standaard vulling
identificatie Uit BGT
type Uit BGT
geometrie Uit BGT
isOnderdeelVan geen mapping gespecificeerd. Dit gegeven zit niet in de brondata, er moet een afleidingsregel voor gemaakt worden.
relatieveHoogteligging Uit BGT. Niet in EMSO aangemerkt als inhoud SOR, maar voor deze beproeving wel interessant om mee te nemen. Zolang we geen 3D hebben...
status Uit BGT
15.4.2.4 Transponering van metadata en historie

Er zijn alleen transponeringsregels geschreven en toegepast voor de BAG data. De BGT is maar in beperkte mate meegenomen, omdat tijdlijn geldigheid en versie-informatie in de BGT niet aanwezig is en er kwaliteitsissues werden gevonden met BGT tijdstipgegevens.

Attribuut Realisatie Toelichting
beginGeldigheid Uit BAG indien mogelijk, anders leeg
eindGeldigheid Uit BAG indien aanwezig, anders leeg
tijdstipRegistratie Uit BAG indien mogelijk, anders BGT?
eindRegistratie Uit BAG indien mogelijk, anders leeg
versie Uit BAG indien mogelijk, anders leeg
beschrijft Domein + identificatie van BAG of BGT object
bronhouder Uit BAG indien mogelijk, anders uit BGT
brondocument Uit BAG indien mogelijk, anders leeg

15.4.3 REST API

De gerealiseerde REST API is een API conform de Nederlandse API strategie [ADR]. Objectinformatie wordt door deze API geretourneerd in HAL + JSON formaat. De API is bedoeld voor het opvragen van een beperkte set objecten en ondersteunt:

  • paginering
  • geometrie in meerdere coördinatenstelsels (RD, ETRS-89)
  • geo-zoeken conform de API strategie, maar meerdere filters kunnen mogelijk gemaakt worden

De API is geconfigureerd met behulp van het DotWebStack Framework. Er wordt een “On the fly” mapping op de lookup API gedaan.

Figuur 27 toont de functionaliteit van de REST API in de vorm van Swagger documentatie.

REST API endpoints
Figuur 27 De endpoints van de REST API

15.4.4 URI Dereferencing Service

De URI Dereferencing service is een heel eenvoudige maar krachtige component, die op basis van de URI identifier van een object de gegevens teruggeeft als RDF. Dit is een van de kernonderdelen van linked data, ook verwoord in Spatial Data on the Web Best Practice 1: geef je objecten een URI identificatie en zorg dat je informatie over het object teruggeeft als die URI wordt opgevraagd. Dat is precies wat deze service doet: als je via de URI Dereferencing Service de identificerende URI van een object via HTTP opvraagt, krijg je gegevens van dat object terug, inclusief http(s) links naar andere objecten.

Belangrijk punt is dat de HTTP URI een implementatie-onafhankelijke identificatie is. Via dezelfde URI kun je gegevens in meerdere formaten terug vragen door gebruik te maken van content negotiation.

Ook bij dit onderdeel geldt: De API is geconfigureerd met behulp van het DotWebStack Framework. Er wordt een “On the fly” mapping op de lookup API gedaan.

15.4.5 OGC API Features

De gerealiseerde OGC Features API maakt het mogelijk om de SOR te integreren met gangbare tooling binnen het GIS / Geo domein. De OGC API Features standaard [ogcapi-features] is de opvolger van WFS maar dan gebaseerd op REST principes. Je kunt er geo-objecten mee opvragen middels een gestandaardiseerde interface, die door GIS tooling wordt ondersteund. In deze High-5 implementeerden we alleen deel 1.

Er is custom programmeerwerk gedaan om de OGC API Features bovenop een andere API te laten functioneren. Er wordt net als bij de andere componenten een "on the fly" mapping gedaan.

Net als de REST API is de OGC API Features beschreven met Swagger documentatie:

OAF Swagger
Figuur 28 Swagger documentatie van OGC API Features

Het lukte tijdens de High-5 om SOR data via de OGC API Features in te laden in open source GIS pakket QGIS.

OAF QGIS
Figuur 29 SOR data in QGis via de OGC API Features

15.4.6 Linked Data API

De Linked Data API biedt toegang tot de SOR conform Linked Data standaarden. Tijdens de High-5 is de Linked Data API verbonden aan de URI Dereferencing Service om de data binnen te halen (dit gebeurt met de snelheid van je internetverbinding) en in de eigen Knowledge Graph op te slaan. Vervolgens kan er in de omgeving van het Kadaster Data Science team van alles mee worden gedaan zoals het integreren met andere datasets. Omdat de data zelfbeschrijvend is en dus in feite 'zegt' dat het geodata is, wordt automatisch een kaartvisualisatie aangeboden voor het bekijken van de data. Op de kaart kun je doorklikken naar een web pagina voor elk object.

KG
Figuur 30 Eén gebouw in de Knowledge graph van de Linked Data API

Tijdens de High-5 zijn een aantal dingen specifiek gerealiseerd met deze data:

  • Gebouwen met verschil in bovenaanzichtgeometrie en maaiveldgeometrie vinden en in 3D visualiseren;
  • Een kaart met daarop gebouwen uit verschillende bouwjaren in verschillende kleuren gevisualiseerd;
  • Integratie met CBS wijk/buurt data en op basis daarvan tonen van nabijheid voorzieningen.
ld gebouw
Figuur 31 3D visualisatie van een gebouw met verschillende bovenaanzicht- en grondvlakgeometrieën

16. Lessons Learned over de implementatie

Dit hoofdstuk beschrijft welke aspecten van implementatie goed gelukt zijn, wat wel lukte maar met moeite, en wat problemen opleverde en misschien zelfs niet gelukt is.

De bevindingen zijn gegroepeerd op onderwerp.

16.1 Bevindingen over het informatiemodel

16.1.1 Ontbrekende gegevens voor bunkers en schuren

Voor bunkers en schuren uit de BGT, die geen corresponderend BAG pand hebben maar wel SOR Gebouw zijn, lopen we tegen het issue aan dat er geen bouwjaar bekend is en dat er geen BAG geometrie is. Deze gegevens moeten dus optioneel of voidable worden in het informatiemodel. In MIM termen betekent voidable: we gebruiken dan mogelijk geen waarde = ja in het informatiemodel.

Als we de attributen bouwjaar en geometrie voidable maken, zijn ze wel verplicht, maar is het toegestaan om een nilwaarde op te nemen en een reden van het ontbreken van het gegeven op te nemen.

De andere optie is om deze attributen optioneel te maken: dan worden ze in hun geheel weg gelaten bij bunkers en schuren. Deze optie is gekozen tijdens de implementatie van de high 5.

Wat uiteindelijk de beste modellering is zal nog worden uitgewerkt.

16.2 Bevindingen over de transponering

Hoewel er allerlei uitdagingen zijn, is gebleken dat de op transponering gebaseerde architectuur werkt. De data kan bij de bron blijven. We doen geen getransformeerde data opslag maar orchestratie on the fly, en het is toch mogelijk om data af te nemen als stroom uit het stopcontact op verschillende manieren. Het Linked Data endpoint doet wel synchrone opslag, omdat dit voor het exploreren nodig is.

16.2.1 Transponering Gebouw en gebouwgerelateerde objecttypen

Over het algemeen bleek: als je eenmaal de transponering van een objecttype gedaan hebt, is de volgende niet zo moeilijk. Transponeren van objecttypen uit de BGT bleek relatief simpel. Deze objecttypen hebben onderling weinig relaties en verschillen niet zo heel veel van elkaar. De objecttypen uit de BAG hebben meer onderlinge relaties en verschillen.

Een kanttekening hierbij is dat zodra andere gegevensbronnen (BRT, WOZ, enz) binnen beschouwing komen, dit nieuwe uitdagingen kan opleveren.

De SOR vereist een aantal administratieve relaties tussen objecttypen. Sommige van deze relaties zijn al aanwezig in de huidige bronregistraties, zoals de relatie tussen Verblijfsobject en Gebouw. Maar de SOR specificeert ook een aantal relaties die nu nog niet administratief worden bijgehouden. Een voorbeeld hiervan is de hoortBij relatie tussen Gebouwcomponent en Gebouw.

Deze in de bron nog niet aanwezige relaties hebben we tijdens de High-5 buiten beschouwing gelaten. De vraag blijft daarom of het mogelijk is relaties die in de bron niet aanwezig zijn, on the fly in de transponeringslaag te gaan bepalen, bijvoorbeeld door ze geometrisch af te leiden. We weten niet of dit performance issues zou opleveren. In dat geval zou mogelijk een tussentijdse opslag van deze relaties nodig zijn (een linkset). En in het uiterste geval kan het ook nodig zijn dat relaties door de bronhouder moeten worden ingewonnen en beheerd, mogelijk met inzet van AI technologie.

Op dit punt is vervolgonderzoek nodig.

16.2.2 Transponering van identificatie

We hebben in de eerdere modelleerfase van deze High-5 al besloten om nu geen SOR identificatie te introduceren, maar hiervoor de identificatie uit de bestaande bronregistraties te gebruiken. Omdat er zowel BAG als BGT panden zijn, die samen in een Gebouw object moeten gevat worden, moest er gekozen worden welke identificatie leidend is. Dit is voor ons het BAG ID geworden.

Er zijn ook SOR gebouwen die geen BAG id hebben, namelijk de BGT OverigBouwwerk objecten van het type Bunker en Schuur. Voor deze SOR gebouwen wordt het BGT id overgenomen.

Een probleem met de identificatie was dat het geen type details bevat. Met andere woorden: op het moment dat de Lookup API een verzoek binnenkrijgt de gegevens behorende bij een object identificatie te leveren, deze API niet weet in welke registratie dit object moet worden opgehaald en in welke objecttype-collectie daar moet worden gekeken. Nu hebben we een slimmigheid gebruikt: BGT_identificatie bevat een “.”, en dit feit gebruikte de Lookup API om te bepalen of de zoekvraag naar de BGT of de BAG API moest worden doorgespeeld. Dat is niet bestendig bij uitbreiding van bronnen van Gebouw (BRT) en andere SOR objecten.

Ook op dit punt is vervolgonderzoek nodig. Is dit probleem bijvoorbeeld op te lossen met een index / linkset oftewel een soort 'wegwijzer' waar de SOR Lookup API kan vinden welke identifier waar gevonden kan worden? Of moeten we wellicht toch een nieuwe SOR identificatie hanteren waaraan dit te zien zou zijn?

Bij het toekennen van een nieuw SOR ID zouden we dan nog kunnen overwegen om dit een verlenging van een bestaand ID te maken zodat herleiding mogelijk is. De bestaande IDs blijven gebruiken is op zich het gemakkelijkst (hoewel wel wel voor elk SOR objecttype moeten bepalen welk ID we hiervoor kiezen, wat voor uit meerdere bronnen samengestelde objecttypen lastig kan zijn) en hergebruik van bestaande IDs is positief. Maar een nieuw SOR ID introduceren betekent wel nóg een identificatie voor afnemers.

16.2.3 Transponering van historie

De transponering van historie is deels gelukt. Met name het historiemodel van de BAG is met succes getransponeerd naar de SOR. Het feit dat in BAG 2.0 een versienummer voor objectgegevens is ingevoerd hielp hierbij.

Het historiemodel van de BGT bleek lastiger. De BGT bevat een beperkt historiemodel met alleen registratietijdstippen, geen geldigheidstijdstippen; het verschilt van dat van de BAG, en houdt geen versienummer bij voor geregistreerde gegevens zoals de BAG dat doet. De ontwikkelaars hadden ook meer parate kennis van de BAG dan de BGT. Het opstellen van transponeringsregels van het BGT historiemodel naar de SOR zou waarschijnlijk zeker enkele dagen onderzoek vergen. Omwille van de tijd hebben we er tijdens de High-5 voor gekozen dit niet te doen.

Omdat het BAG historiemodel wel was getransponeerd konden we bevestigen of tijdreizen mogelijk was en dit bleek het geval. De Lookup API kan tijdreisvragen beantwoorden op basis van de historie-informatie uit de BAG. In de High-5 gebruiken we dit alleen om het actueel geldige informatieobject op te vragen, maar een zoekvraag naar een historisch tijdstip zou even goed mogelijk zijn.

Bij het bekijken van extracten uit de BGT ontdekten we bij toeval een eigenaardigheid: een object met meerdere instanties, waarvan de gegevens volledig hetzelfde waren, maar met twee verschillende LV-publicatie-tijdstippen. Dit soort datakwaliteitsissues kan bij de transponering van gegevens uiteraard voor problemen zorgen. Een uitgangspunt is dan ook dat de datakwaliteit in orde moet zijn.

Er is meer tijd nodig om dit onderwerp, het transponeren van historie van niet alleen de BAG maar ook de BGT en andere basisregistraties die in de SOR een rol spelen, uit te zoeken. Hierbij is inhoudelijke kennis van het historiemodel in deze basisregistraties onontbeerlijk.

16.2.4 Transponering van metadata

De transponering van overige metadata is grotendeels gelukt. We hebben metadata over de herkomst van objecten meegenomen in de transponering zoals van tevoren beschreven in § 4. Modelleerpatronen voor metadata. Hierdoor kun je aan de SOR data zien uit welke bronobjecten uit de BAG en/of BGT deze is opgebouwd. Bij deze bronobjecten kun je dan ook terugvinden wat het oorspronkelijke brondocument en de bronhouder is, als deze gegevens in de bronregistratie beschikbaar zijn.

Zie § 15.4.2.4 Transponering van metadata en historie voor het overzicht van de transponeringsregels voor metadata.

Noot

16.2.5 Toevoegen Open Bouwwerk

Omdat we voor de SOR gebouwen al moesten putten uit de BGT OverigBouwwerk objecten om daar de schuren en bunkers uit te halen, bleek het heel weinig werk te zijn om ook SOR Open Bouwwerk op te nemen. Deze objecten zijn namelijk gebaseerd op een ander BGT OverigBouwwerk type (Open loods en Overkapping).

Open Bouwwerk is toegevoegd aan de Lookup API SOR en daarna ook aan de REST API en de URI Dereferencing service. Dat was heel gemakkelijk om te doen. Als je eenmaal een query hebt voor een objecttype, is het eenvoudig om hier verder op voort te bouwen. Dit wijst op een zekere flexibiliteit in het systeem. Positief!

Een probleem met de transponering van Open Bouwwerk is dat in de BAG zogenaamde "open frontstallen" staan die als Pand getypeerd zijn (zie hiervoor de Praktijkhandreiking BAG), maar die in de SOR Open Bouwwerk moeten worden. Deze gevallen konden we nu niet in de transponering meenemen omdat er geen mapping regel voor was. Het is niet duidelijk of dit in de data te herkennen is en of automatisch transponeren überhaupt mogelijk is.

16.2.6 Mapping specificatie

Het is beoogd een declaratieve, machineleesbare specificatie van de mapping te maken tussen BAG/BGT en SOR en deze uit te laten voeren door intelligente software. De hele intelligentie van de transponering kan zo buiten de logica van de APIs geplaatst worden. De Lookup API hoeft alleen de mapping uit te voeren en kan daardoor generiek blijven. De vertaalspecificaties moeten twee kanten op werken voor een functionerende API: om gegevens in de bron(nen) te kunnen vinden gegeven een zoekvraag; en om gegevens te kunnen leveren in de doelstructuur (SOR model).

Tijdens deze high 5 is een stap gezet richting het declaratief maken van de mapping. Dit moet nog verder uitgewerkt worden.

Noot

Deze declaratieve, machineleesbare mappingspecificatie sluit aan bij MIM en zit qua opzet dichtbij de taal die we gebruiken voor het informatiemodel. Technisch is het een soort YAML dialect dat machineleesbaar is en herkenbaar voor ontwikkelaars.

Het Linked Data team gaf tijdens de High-5 aan dat zij ook graag de transformatieregels willen kunnen lezen en uitvoeren. De transformatieregels moeten breder beschikbaar / toepasbaar zijn dan alleen op één plek in de Lookup API (en dus ook implementatie / techniek onafhankelijk). Ze zouden idealiter conceptueel moeten worden vastgelegd op één plek, door of met behulp van inhoudelijk experts, en moeten worden geïmplementeerd in meerdere formaten en zo op meerdere plekken inzetbaar zijn.

Een vervolgstap zou kunnen zijn om samen verder te werken aan een gestandaardiseerde multi-inzetbare transponeringstaal.

Sommige transponeringsregels zijn heel eenvoudig, bijvoorbeeld die voor het vullen van het bouwjaar. Andere zijn ingewikkelder doordat bepaalde algemeen voorkomende gegevens in de huidige basisregistraties niet eenduidig gemodelleerd zijn. Een voorbeeld is het gegeven status, i.e. levensfase van een object. In de BAG zitten andere statussen dan in de BGT. De in de SOR gedefinieerde statussen zijn weer anders.

16.2.7 Gebruik van begrippenkader in transponering

Het bleek mogelijk om bij de transponering van gegevens slim gebruik te maken van relaties tussen begrippen in het begrippenkader van de SOR (de experimentele variant voor de High-5). Dit is toegepast bij de transponering van gegevens over levenscyclus (status).

Het begrippenkader is uitgedrukt in SKOS [skos-primer], en dit biedt mogelijkheden om semantische relaties te leggen tussen begrippenkaders. Wat we gedaan hebben is de status begrippen uit het SOR begrippenkader verbinden met de overeenkomstige begrippen van BAG en BGT (die ook gepubliceerde begrippenkaders hebben) door middel van mapping relaties.

De orchestratielaag kon deze relaties tussen begrippen gebruiken voor de transponering en de Lookup API kan daardoor gegeven een SOR status een BAG status vinden of gegeven een BAG status een SOR status teruggeven.

16.2.8 Specificatie vanuit bron of doel

Je kunt bij het maken van zo'n mappingspecificatie twee kanten op.

  1. Je neemt de bron als uitgangspunt, en specificeert voor elk brongegeven wat de naam, structuur en inhoud van het resultaatgegeven moet zijn; een zogenaamde "push" transformatie.
  2. Je neemt het gewenste resultaat als uitgangspunt, en specificeert voor elk resultaatgegeven waar je dat precies in de brondata kunt vinden; een zogenaamde "pull" transformatie ofwel "cherry-picking".

Onze eerste uitdaging was: welke van deze aanpakken kunnen we het beste als uitgangspunt nemen? We hebben gekozen voor aanpak 2. Waarom?

  • In algemene zin is een push aanpak meer geschikt voor een mapping waarbij de doelstructuur erg lijkt op de bronstructuur, terwijl een pull aanpak beter werkt voor een mapping waarbij de doelstructuur erg afwijkt van de bron. De doel- en brongegevensstructuur verschillen niet fundamenteel van elkaar, wat zou pleiten voor een push aanpak; maar er zijn meer argumenten.
  • De SOR is gespecificeerd vanuit het gewenste einddoel en SOR objecten zijn daardoor vaak een combinatie van meerdere bronobjecten, zodat er niet één enkel bronobject als uitganspunt genomen kan worden;
  • De pull / cherry picking aanpak leent zich meer voor een geleidelijk ontwikkelproces waarbij er steeds meer gegevens aan de SOR objecten kunnen worden toegevoegd, ongeacht uit welke bronregistratie ze komen.

16.2.9 Query planning

Om de transponering te kunnen uitvoeren moet je ook de orchestratie logica vastleggen: de kennis over in welke gegevensbron je welke gegevens kan vinden en in welke volgorde je het beste de bronnen kan raadplegen als je er meerdere nodig hebt (wat in de SOR natuurlijk vaak zo is).

De volgorde van het uitvoeren van de benodigde queries op een slimme manier bepalen is een uitdaging. We hopen dit op basis van configuratie, dus op basis van de declaratief uitgedrukte transponeringsregels te kunnen doen.

Het specifiek uitprogrammeren van deze volgorde in code moet vermeden worden.

16.3 Bevindingen over Lookup APIs en orchestratie

Deze bevindingen gaan over de orchestratie en over de Lookup APIs die zowel in de onderste als de bovenste laag (de SOR laag) voorkomen.

16.3.1 Gestandaardiseerd GraphQL profiel

De Lookup API SOR, Lookup API BGT en Lookup API BAG hebben om diverse redenen een GraphQL endpoint. GraphQL is een low level standaard waarmee je alle kanten op kunt, en er is nog geen gestandaardiseerd profiel voor, dat beschrijft hoe je bijvoorbeeld omgaat met naamgeving, filteren, paginering, sortering etc. zoals de API Design Rules (uit de NL API strategie) dat doen voor REST APIs.

Er is in elke afnemende API van de Lookup API SOR een mapping nodig waarin de data wordt gefilterd en omgezet naar de gewenste structuur. Deze mapping moet beheerd worden.

Hetzelfde geldt bij de Lookup API SOR zelf, die bevragingen doet bij de Lookup API BGT en Lookup API BAG. Ook voor deze interfaces moet in de Lookup API SOR specifieke code geschreven worden. In deze High-5 setting is dit nog te overzien, maar in de grotere context van de SOR is het programmeren en beheren van de orchestratie niet meer te doen zonder gestandaardiseerd GraphQL profiel.

Hier lopen we in feite tegen hetzelfde probleem aan als bij de eerste High 5 demonstrator die werd gebouwd bovenop bestaande, APIs die niet aan een gestandaardiseerd profiel voldeden. De laag met de semantiek en orchestratie zou niet te beheren zijn, concludeerden we toen.

We denken wel dat dit deels te beheersen is, mits er gestandaardiseerd wordt. Dit brengt de hoeveelheid specifieke code aanzienlijk terug. Een belangrijke bevinding van deze High-5 is dus dat efficiënte orchestratie uniformiteit in Lookup API’s vereist. Een gestandaardiseerd GraphQL profiel is nodig, dat in ieder geval in de context van de SOR architectuur, voor de samenhangende registraties, wordt gehanteerd. In dit profiel kunnen net zoals in de API strategie voor REST APIs vaak gehanteerde interface elementen en toegangspatronen t.b.v. orchestratie (o.a. batching) gestandaardiseerd worden.

16.3.2 Batch bevraging

Als een gebruiker aan de SOR API een collectie van objecten opvraagt, moet de Lookup API SOR daarvoor eerst naar de BAG, en vervolgens naar de BGT met een set BAG identificaties om de aanvullende BGT gegevens erbij te vinden. In die tweede stap wordt nu per identificatie een individuele zoekvraag gesteld. Het zou handig zijn om die te kunnen bundelen in een batch bevraging.

Dit is vergelijkbaar met de constatering vanuit het SPARQL endpoint dat een bulkbevraging nodig was. Dit geldt dus voor zowel de Lookup API SOR als die van de BAG en BGT in de laag Ontsluiting data.

16.3.3 Performance en andere non-functionals

Performance van de APIs is een belangrijk aspect, dat samenhangt met het eerder genoemde query planning. Cruciaal is dat elk van de services die data leveren voor de SOR op zich al goede performance moeten hebben, anders kunnen georchestreerde SOR services ook nooit snel worden. Non-functional aspecten zijn in deze architectuur extra belangrijk want je bent zo zwak als de zwakste schakel.

In deze High-5 setting bleken de extra schakels in het netwerk (APIs bovenop APIs) qua performance verwaarloosbaar: elk stapje kost maar enkele milliseconden. Ook de impact van on the fly transponering was heel beperkt, vooral bij eenvoudige omzettingen zoals een gegeven van naam veranderen. Een belangrijke kanttekening is wel dat we natuurlijk niet met grote datavolumes gewerkt hebben. Mocht performance wel een issue worden, dan kan daaraan nog veel gedaan worden, bijvoorbeeld onderdelen van een query tegelijktijdig uitvoeren.

Bij complexere transponeringsregels die zwaar op de techniek drukken kan een afweging gemaakt worden, of je die via de techniek moet oplossen of, als ze waarde opleveren, in de bron van de basisregistraties.

Ruimtelijke vragen zijn niet per sé een aandachtspunt wat betreft performance. Maar hoge performance loopt wel in het algemeen gevaar als je een vraag stelt waarop een grote selectie aan objecten terugkomt. Hoe ga je die sorteren, pagineren etc.? Dat zijn zware operaties.

De DiS Geo architectuurbeschrijving [ARCH] noemt een aantal niet-functionele eisen die van belang zijn voor SOR voorzieningen, waaronder performance maar ook andere eisen. Dat deze eisen aan de SOR gesteld worden betekent dat de services die onder de SOR liggen hier ook aan moeten voldoen. Ze moeten allemaal een hoge uptime hebben, goede foutafhandeling hebben, fouten en performance moeten traceerbaar zijn, etc.

Aanbeveling: Een verdere uitwerking van de SOR voorzieningen architectuur / de niet-functionele eisen aan de onderliggende services is nodig.

16.3.4 Versionering van API's

In de loop der tijd zullen APIs worden doorontwikkeld en veranderen - zoals ook de onderliggende informatiemodellen. Dit is een uitdaging: als de onderliggende APIs van de SOR veranderen raakt dit de orchestratie / transponeringslaag. Semantic versioning is daarom nodig.

16.4 Bevindingen over de REST API

Het realiseren van de REST API verliep zonder bijzondere problemen en kostte niet veel tijd (binnen 2 dagen gerealiseerd).

Zoals bij alle van de Lookup API afnemende services was er een on the fly mapping nodig van het graphql endpoint naar de gewenste gegevensstructuur in de REST API.

16.5 Bevindingen over de URI Dereferencing Service

Net als de REST API was deze snel te realiseren en waren er geen problemen mee. Een beperking is wel dat je per definitie altijd maar één object tegelijk kan opvragen aan deze service. In sommige situaties is een bulk bevraging handiger. Dat biedt deze service, vanwege de aard van URI dereferencing, niet.

Heel mooi is dat alle endpoints, dus zowel de REST API, de OGC Features API en de Linked Data API, uiteindelijk naar dezelfde URI voor een gegeven object oplossen (dereferencing). Elk object heeft dus een universele URI identificatie die werkt over meerdere technische ontsluitingen heen.

16.6 Bevindingen over OGC API Features

16.6.1 Aansluiten op Lookup API was niet eenvoudig

Het aansluiten van de OGC API Features op de graphql gebaseerde Lookup API SOR was niet eenvoudig. Er moest specifieke code worden geschreven om de data te verkrijgen en om te vormen (bijvoorbeeld voor het uitfilteren van attributen en 'plat slaan' van geneste structuur). Voor een OGC API Features is dit niet nodig als de data al in een Postgres database of een Geopackage bestand zit in de juiste structuur. De ETL stappen zijn dan al gedaan; in de huidige situatie wordt er in feite nog ETL gedaan IN de API op het laatste moment.

Het schrijven van deze specifieke code is meer werk ten opzichte van het gebruik van een standaard GIS opslagmethode en blijkt bovendien ook wat lastiger dan verwacht. Je krijgt ook een beheerslast: als er in de Lookup API gegevens bij komen, moet er in de specifieke code ook weer iets aangepast worden met betrekking tot het wel of niet doorleveren van die gegevens.

16.6.2 Coördinaatreferentiesysteem

OGC API Features: Part 1 schrijft als coördinaatreferentiesysteem WGS 84 longitude/latitude voor (i.e. http://www.opengis.net/def/crs/OGC/1.3/CRS84). De Lookup API serveerde standaard de gegevens in het coördinaatreferentiesysteem van de bron, zijnde RD.

Om dit op te lossen is in de Lookup API de optie geïmplementeerd om de gegevens in plaats van in RD, in ETRS 89 op te vragen. Tussen ETRS 89 en WGS 84 zit maar een kleine afwijking, en een hoge nauwkeurigheid is in dit geval niet belangrijk, dus we kunnen WGS 84 gelijkstellen aan ETRS 89, zoals beschreven in de nieuwe handreiking over coördinaatreferentiesystemen van Geonovum [CRS]. De ETRS 89 coördinaten kunnen in de OGC API Features opgenomen worden in de GeoJSON output als zijnde WGS 84.

16.6.3 "Geo-Graphql"

Vanuit de realisatie van de OGC API Features zien we, naast behoefte aan een standaard Graphql profiel, ook behoefte aan een standaard afspraak over 'geo-graphql', dat wil zeggen over hoe je ruimtelijke vragen kan stellen aan een Graphql endpoint.

Het is niet gelukt om de OGC API Features op de LookUP API aan te sluiten zonder hard codeerwerk. Het lijkt erop dat een profiel/standaard kan helpen, maar zelfs als dat er is kan er nog hard codeerwerk nodig zijn. Op zich is dit niet heel veel werk maar het zegt wel iets en het betekent dat er mogelijk programmeerwerk nodig is bij latere wijzigingen in APIs. Dit is niet wenselijk want het maakt de oplossing beduidend minder flexibel.

16.7 Linked Data API en Knowledge Graph

Al snel op de eerste dag lukte het om de knowledge graph te vullen door de URI Dereferencing Service te bevragen. Dit was zeer eenvoudig te implementeren omdat de Web- en Linked Data standaarden voor interoperabiliteit zorgen. Zodra de data in de knowledge graph zat, was het ook eenvoudig om daar vervolgens integrale bevragingen op te doen en de resultaten te visualiseren.

Ook was het goed mogelijk de data te integreren met andere beschikbare linked data. Hiervoor is gewerkt met een linkset waarin de relatie van BAG panden met de buurt waarin ze liggen administratief is uitgedrukt.

16.7.1 Bulkbevraging

Ten behoeve van de knowledge graph is er behoefte aan het in bulk kunnen opvragen van een grote hoeveelheid data uit de Lookup API. Tijdens deze High-5 hebben we bulk bevragingen echter bewust buiten scope geplaatst (moeilijk binnen 3 dagen te realiseren) en de Lookup API biedt deze mogelijkheid nu dus niet. Daarom werd in eerste instantie de RDF data voor de hele gemeente Dronten via puntbevraging (per object op basis van een lijst met alle identifiers binnen de gemeente) opgehaald vanuit de URI Dereferencing Service. Omdat dit nogal lang duurt is als workaround ervoor gekozen om alleen de data voor het dorp Swifterbant op te vragen.

Uiteraard wordt, zodra er meer tijd is, zo'n bulkbevragingsvoorziening wel gerealiseerd.

A. IMSOR Gebouw model - eerste iteratie

Hieronder zijn de tijdens het eerste deel van de High-5 (in augustus 2021) gemaakte diagrammen afgebeeld die het IMSOR Gebouw model weergeven. In november is dit model ingrijpend aangepast. Dit is te vinden in § 8. IMSOR Gebouw.

Onderstaande geeft de verouderde versie van het IMSOR Gebouw model weer:

imsor-gebouw
Figuur 32 IMSOR Gebouw
imsor-gebouw-sector
Figuur 33 IMSOR Gebouw inclusief semantische koppeling van registraties

B. Referenties

B.1 Normatieve referenties

[ADR]
API Design Rules (Nederlandse API Strategie IIa). Geonovum. Definitief. URL: https://publicatie.centrumvoorstandaarden.nl/api/adr/
[ARCH]
DiS Geo: Architectuurbeschrijving Voorzieningen Samenhangende Objectenregistratie. Geonovum. Versie ter vaststelling. URL: https://docs.geostandaarden.nl/disgeo/arch/
[CRS]
Handreiking Gebruik coördinaatreferentiesystemen bij uitwisseling en visualisatie van geo-informatie. Geonovum. Consultatieversie. URL: https://docs.geostandaarden.nl/crs/cv-hr-crs-20211125/#transformatie-tussen-etrs89-en-itrs-wgs-84
[EMSO]
Eisen aan model samenhangende objectregistratie. Sandra Leijten; Marcel Rietdijk; Dick Krijtenburg. Geonovum. Definitief. URL: https://docs.geostandaarden.nl/disgeo/emso/
[GENDOC]
Overzicht generieke onderwerpen voor DisGeo informatiemodellering. Geonovum. levend document. URL: https://geonovum.github.io/disgeo-imsor/documentatie/
[GraphQL]
GraphQL. July 2015. Working Draft. URL: https://facebook.github.io/graphql/
[MIM]
MIM - Metamodel Informatie Modellering. Geonovum. 2020-10-23. Definitief. URL: https://docs.geostandaarden.nl/mim/mim/
[MODPR]
Modelleerprincipes samenhangende objectenregistratie. Geonovum. levend document. URL: https://geonovum.github.io/disgeo-imsor/modelleerprincipes/
[MPSOR]
Modelleerprincipes samenhangende objectenregistratie. Geonovum. Werkversie 12 augustus 2021. URL: https://geonovum.github.io/disgeo-imsor/modelleerprincipes/
[NEN3610-2021-ontw]
NEN-3610 Basismodel geo-informatie. NEN. 2021. Ontwerp.
[ogcapi-features]
OGC API - Features - Part 1: Core. Open Geospatial Consortium. Approved. URL: http://docs.opengeospatial.org/is/17-069r3/17-069r3.html
[PROV-DM]
PROV-DM: The PROV Data Model. Luc Moreau; Paolo Missier. W3C. 30 April 2013. W3C Recommendation. URL: https://www.w3.org/TR/prov-dm/
[PROV-O]
PROV-O: The PROV Ontology. Timothy Lebo; Satya Sahoo; Deborah McGuinness. W3C. 30 April 2013. W3C Recommendation. URL: https://www.w3.org/TR/prov-o/
[SHACL-AF]
SHACL Advanced Features. Holger Knublauch; Dean Allemang; Simon Steyskal. W3C. 8 June 2017. W3C Note. URL: https://www.w3.org/TR/shacl-af/
[skos-primer]
SKOS Simple Knowledge Organization System Primer. Antoine Isaac; Ed Summers. W3C. 18 August 2009. W3C Note. URL: https://www.w3.org/TR/skos-primer/