DisGeo demo 3a Lessons Learned

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.

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:

• een RDF model i.e. een samenhangend semantisch model van het gekozen afgebakende onderwerp
• OAS 3 API’s

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:

7. 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?
8. Hoe kunnen we de verschillende producten (SKOS begrippenkader, UML informatiemodel, RDF model) publiceren?
9. 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:

• Energielabels
• Energieafgiftepunten

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:

• Diverse haken en ogen;
• API maturiteit viel tegen;
• APIs zijn de nieuwe silo’s;
• Semantische samenhang daarbovenop realiseren vereist een onderhoudsgevoelige semantische laag;
• Er is governance op het snijvlak nodig.

2. 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:

• Linked Data is geschikt (onmisbaar) om de DisGeo ambities met betrekking tot het in samenhang bevragen van de basisregistraties te realiseren;
• Zowel als directe toegangslaag, en als basis voor API's en viewers;
• Er zijn geen grote technische belemmeringen gevonden.

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:

• Hoofdstuk § 1. Inleiding (dit hoofdstuk): de integrale inleiding over de gehele High-5 activiteit (het geheel van drie sessies).
• Hoofdstuk 2 t/m 12: beschrijven de semantische modellering en transponering en alles wat daarbij kwam kijken.
• Hoofdstuk § 13. Lessons Learned informatiemodellering beschrijft de de opgedane inzichten en aanbevelingen over informatiemodellering en over het specificeren van de transponering.
• Hoofdstuk 14 t/m 16: beschrijven de benodigdheden voor implementatie en de resultaten van de implementatie zelf.
• Hoofdstuk § 16. Lessons Learned over de implementatie: beschrijft de opgedane inzichten en aanbevelingen over de implementatie.

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:

• Je kan altijd van een verblijfsobject het energielabel vinden, maar een energielabel kan aan verschillende verblijfsobjecten hangen.
• Energielabels kunnen gerelateerd zijn aan een deel van een gebouw of aan een verblijfsobject. Wat dit 'deel van gebouw' is, is nog onduidelijk. Soms is dit een ruimtelijke 'koker' binnen een flatbebouw; daar lijkt een soort gebouwzone handig voor, maar in de huidige [EMSO] definitie past dat niet, want een gebouwzone moet zich volgens die definitie binnen een verdieping bevinden. Je zou hiervoor iets als de CityGML BuildingUnit moeten hebben.

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:

• BAG
• BGT
• WOZ
• EPBD - Energielabels
• EAN - Energie afgiftepunten

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.

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

• Gegevenscatalogus BAG
• Datamodel BAG
• Begrippenkader BAG

Informatiemodel BGT

• Gegevenscatalogus BGT
• Informatiemodel IMGeo EAP en XMI
• Begrippenkader IMGeo

Informatiemodel BRT

• Gegevenscatalogus BRT
• Datamodel BRT
• Informatiemodel BRT EAP en XMI
• Begrippenkader BRT

Informatiemodel WOZ

• Documentatie IMWOZ, bespreekversie 6-8-2021

Informatie over energielabels

• Informatiepagina RVO

Informatie over energieafgiftepunten

• Casebeschrijving energieafgiftepunten

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:

• Het samenvoegen van waardelijsten, zoals bijvoorbeeld in de SOR gebeurt met de waardelijsten die de mogelijke statussen van objecten opsommen. Hierbij kan het gaan om hiërarchische lijsten die moeten worden vertaald naar een geaggregeerde status (zie [EMSO]).
• Attribuutsoorten zoals 'type' die meerdere keren voorkomen en dus naamgevingsconflicten kunnen opleveren.

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:

• § 4.1.2 Modelleerpatroon voor de beschrijving van de afleiding van SOR-informatieobjecten
• § 9. Vertalingsregels en afleidingsregels
• § 10. Inventarisatie van manieren om vertaalspecificaties vast te leggen
• § 11. Gebouwen van bron naar SOR

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:

• § 4. Modelleerpatronen voor metadata

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:

• Relateren van gebouwcomponent aan gebouw
• Relateren van BRT gebouw aan gebouwblok

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

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.

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

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.

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

5.2 Uitgangspunten

• SOR afspraak: van alle gegevens moet bekend zijn wanneer de gegevens geldig zijn en wanneer ze beschikbaar/geregistreerd zijn.
• We modelleren conform MIM - maar MIM kent nog geen metadata. We volgen daarom de huidige stand van de expertgroep modellering SOR.
• We modelleren conform NEN3610 - zie modellering historie aldaar.
• De uitwerking is conform de specificatie van een tijdreis zoals beschreven in de NL API strategie (en hoe dit bv. in de LVBAG werkt, die deze implementeert).
• De uitwerking is in lijn met de SOR en met hoe de basisregistraties nu werken (de data die beschikbaar is of beschikbaar gemaakt zou kunnen worden).

Dit betekent voor dit inhoudelijke punt:

• We stellen het object centraal - d.w.z. we willen gegevens over het gebouw in de werkelijkheid leveren, en we doen dit door de registratiegegevens over het informatieobject te scheiden van de informatie over het object.
• We geven de tijdlijnen per set gegevens over een object aan. Dit heet ook wel een versie van een informatieobject. Afnemers willen gegevens van/over een object weten en wanneer deze, dit setje, geldig is en beschikaar is gekomen zodat ze het (hadden kunnen) weten.

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:

0. Definities van de tijdlijn geldigheid en de tijdlijn registratie.
1. 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.
2. Niet elke geo-basisregistratie kent nu beide tijdlijnen. Maar informatie over wanneer gegevens geldig en beschikbaar/geregistreerd zijn is wel beschikbaar.
3. 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?
4. 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.
5. 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:

• Elke Landelijke Voorziening (LV) die een verzameling is van een basisregistratie heeft een eigen tijdlijn van verwerking in de LV. We onderkennen dus tijdstipRegistratie bij de bronhouder en tijdstipRegistratie bij de LV.
• Van elk gegeven houden we het registratietijdstip bij. Dit geldt ook voor wanneer een beginGeldigheid of eindGeldigheid is geregisteerd in een basisregistratie en in een LV. Elke versie van een informatieobject heeft een begin geldigheid, en het tijdstip van de registratie van een versie van een informatieobject geeft (ook) aan wanneer deze begin geldigheid is geregistreerd. Evenzo geldt dit voor de einde geldigheid, het tijdstip waarop eind geldigheid geregistreerd wordt moet bekend zijn en eind registratie geeft (ook) aan wanneer deze eind geldigheid is geregistreerd.

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.

• Wanneer een SOR object meerdere identificaties heeft, dan betekent dit dat je elk afzonderlijk kan gebruiken als identificatie, en dat de informatieobjecten uit de onderliggende basisregistraties over hetzelfde SOR object en hetzelfde object in de werkelijkheid gaan.

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:

• De tijdlijn geldigheid en de tijdlijn registratie leveren (dit kan zijn via een interne afleiding in de basisregistratie).
• De NL AP strategie geldigOp (moment in de tijdlijn geldigheid) en beschikbaarOp (moment in de tijdlijn registratie) implementeren.
• Vanuit de basisregistratie een eindstatus leveren (bekijk of je in de basisregistratie deze ook registreert, of dat je deze afleidt).

Vertaalspecificatie tijdlijnen:

• BAG: kent beide tijdlijnen. Geen vertaling nodig.
• WOZ: kent beide tijdlijnen. Geen vertaling nodig.
• BGT: kent nog geen tijdlijn geldigheid.

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

• begin geldigheid = tijdstip registratie
• eind geldigheid = eindRegistratie. Wellicht nog wat logica rondom geconstateerd.

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.

• Voor de geldigOp parameter wordt altijd een DatumTijd gebruikt.
• Bij meerdere versies van een informatieobject op een dag vinden we bij deze geldigOp altijd de laatste de meest actuele voor die dag. We gebruiken dus niet 00:00:01 en 00:00:02 enz. Hier zijn we data aan het bijverzinnen.

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

• Voor de geldigOp parameter wordt altijd een datum gebruikt.
• Bij meerdere versies van een informatieobject op een dag vinden we bij deze geldigOp altijd de laatste de meest actuele voor die dag, mits dit verantwoord kan bij elke basisregistratie. Dit kan als de betekenis van meerdere versies op een dag is, dat de laatste vigerend is vanaf het moment dat die versie is ontstaan.

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.

• Voor de geldigOp parameter wordt altijd een datum gebruikt.
• Bij meerdere versies van een informatieobject op een dag vinden we bij deze geldigOp altijd de laatste de meest actuele voor die dag.
• De implicatie van deze optie is dat een basisregistratie om moet kunnen gaan met wanneer er meerdere versies op 1 dag geldig zijn en deze kan onderscheiden van elkaar.

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

• Geef van elk gegeven uit basisregistratie 1 aan: herkomst basisregistratie1, en de historie metagegevens zijn: begin geldigheid t1 -
• Geef van elk gegeven uit basisregistratie 2 aan: herkomst basisregistratie2, en de historie metagegevens zijn: begin geldigheid t3 -

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:

• tijdstipRegistratie: het moment waarop begin geldigheid is geregistreerd.
• eindRegistatie: het moment waarop de eind geldigheid is geregistreerd/bepaald.

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.

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.

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

Fictief voorbeeld uit de WOZ

5.6 Aanbevelingen voor vervolg (2e high-5)

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

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

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.

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.

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.

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.

6.6 Vergelijkingstabel

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.

• optie 1: Deze koppeling zou een beheerde relatie kunnen zijn vanuit een bestaand object uit een andere bron naar een SOR object.
• optie 2: Deze koppeling zou een nieuw "koppeling" object kunnen zijn, een geobjectiveerde relatie, die een bestaand object uit een andere bron met een SOR object koppelt. Deze verandert het SOR object niet en verandert het eigen bronobject niet. Je zou dit een koppelklasse kunnen noemen.
• optie 3: Deze koppeling zou een uitbreiding of aanvulling kunnen zijn van een bestaand SOR objecttype.

Voorbeelden van deze koppelingen zijn:

• De EAN-BAG koppeling (beheerde relatie vanuit een eigen object, het energieafgiftepunt, uit een andere bron naar een BR/SOR object)
• De BRK-BAG koppeling (koppelklasse die beide bronnen niet aanpast)
• De BGT-BAG koppeling (Semantische relatie tussen BGT Pand en BAG Pand)

Uitgangspunten:

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

Voordelen:

• Er is geen impact op de SOR, maar het koppelt wel beide bronnen aan elkaar;
• Er ontstaat een eco-systeem waarmee informatie uit bronnen gekoppeld kan worden met de SOR en de basisregistraties.
• Via deze koppelingen zijn andere bronnen ook met elkaar te koppelen. Als een bron A met object A1 een koppeling heeft met SOR object S1 en een andere bron B met object B1 heeft deze koppeling ook, dan zijn ook A1 en B1 ook (indirect) gekoppeld. Afhankelijk van de semantiek van de koppelingen naar S kan deze indirecte koppeling zelfs verder gebruikt worden.

Implicaties:

• Andere bronnen (moeten) gaan koppelen met de SOR (koppelingen naar basisregistraties worden vervangen door koppelingen naar de SOR);

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:

• Maak goed duidelijk wat de herkomst van het gegeven is qua bron - uit de SOR of uit een externe bron, bijvoorbeeld het energie domein;
• Wanneer je wilt meedoen in het samenhangende stelsel zal jouw dataset moeten voldoen aan dezelde logische aspecten als de SOR
• voor tijdreizen is dezelfde uitdrukking van tijdlijnen nodig
• voor het kunnen koppelen of platslaan van identificatie is dezelfde manier van identificeren nodig

Dat levert de volgende voordelen op:

• Afnemers kunnen via de ontsluiting van het samenhangende stelsel informatie uit verschillende datasets in combinatie met de SOR informatie opvragen, zonder dat ze deze combinatie zelf moeten maen.
• Een afnemer hoeft niet de bronnen apart te bevragen en zelf de software te ontwikkelen;
• De bron-beheerder en de SOR-beheerder kunnen er samen voor zorgen dat het informatieproduct functioneel helemaal goed/juist is, afnemers hoeven dit niet te doen.

Daarbij spelen de volgende implicaties:

• De verantwoordelijkheid van het meeleveren van gegevens komt bij de informatieproductleverancier te liggen (in overleg met de SOR);
• De eisen aan gegevens voor basisregistraties gaan ook gelden voor de informatievoorziening die het informatieproduct levert, zoals de beschrijving en de standaarden die hiervoor gelden, de historie tijdlijnen en tijdreis mogelijkheden.

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.

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

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.

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

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

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

Implicaties:

• Je kunt jouw objectinformatie samenvoegen met objectinformatie uit de SOR zonder de identificatie her te gebruiken.
• De isGelijkAan relatie kan op verschillende manieren gelegd worden. Zie § 7.2.2 Relateren van verschillende objecttypes

7.3 Aanbeveling

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

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:

• Het gegeven is aanwezig in een bronregistratie en moet worden vertaald naar een gegeven in de SOR (en hierbij heb je dan nog allerlei gradaties van eenvoudige naar complexe mappings). Bijvoorbeeld: het gegeven bouwlaag van WOZ deelobject kan worden vertaald naar bouwlaagnummer van SOR Gebouwzone.
• Het gegeven is niet als zodanig aanwezig in een bronregistratie, maar kan wel worden afgeleid. Bijvoorbeeld: de 2.5D geometrie van Gebouwlaag. Gebouwlaag zit als attribuut in de WOZ, maar niet met een eigen geometrie. Dit gegeven kan op een slimme manier wellicht wel worden afgeleid uit de in WOZ en BAG aanwezige gegevens over 2D geometrie, gebouwtype, oppervlakte en bouwjaar.

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:

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 manier om data te verkrijgen;
• Een manier om over een deel van de data te itereren;
• Een mapping naar het doelmodel.

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

• Gebouw
• Gebouwcomponent
• Open bouwwerk
• Installatie
• Verblijfsobject

Niet in scope uit EMSO paragraaf 5.3:

• Bouwlaag, dit is een nieuw objecttype
• Ruimte, dit is een nieuw objecttype
• Toegangsdeur, dit is een ('grotendeels') nieuw objecttype

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

BAG:

• Pand
• Verblijfsobject

BGT:

• Pand
• OverigBouwwerk type= Bunker | Schuur | Open loods | Overkapping
• Gebouwinstallatie type= Bordes | Luifel | Toegangstrap
• Kunstwerkdeel type= Perron

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

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

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:

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.

• Zie: IMGeo-Object tijdstipRegistratie (8.1.4)
• Bv. voorkomen 1, IMGeo-Object tijdstipRegistratie bij bronhouder is 2-1-2021 (ingewonnen op 1-1, maar geregistreerd op 2-1)
• Dit wordt in IM Gebouw, voorkomen 1, beginGeldigheid is 2-1-2021

Gewenst gegeven: eindGeldigheid van een voorkomen van object

• Zie: IMGeo-Object eindRegistratie (8.1.5)
• Bv. voorkomen 1, IMGeo-Object eindRegistratie (8.1.5) bij bronhouder is 2-3-2021
• Dit wordt in IM Gebouw, voorkomen 1, eindGeldigheid is 2-3-2021

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

Gewenst gegeven: tijdstipRegistratie in LVBGT van een voorkomen van object

• Zie: IMGeo-Object LV-Publicatiedatum (8.1.6)
• Bv. voorkomen 1, LVBGT, Publicatiedatum 3-1-2021
• Dit wordt in IM Gebouw, voorkomen 1, tijdstipRegistratieLV is 3-1-2021

Gewenst gegeven: eindRegistratie in LVBGT van een voorkomen van object

• Zie: IMGeo-Object LV-Publicatiedatum (8.1.6) van het opvolgende voorkomen.
• Bv. voorkomen 2, Publicatiedatum 3-3-2021
• Dit wordt in IM Gebouw, voorkomen 1, eindRegistratieLV is 3-3-2021

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:

• Alle gegevens hetzelfde als het laatste versie uit de (LV)BGT, die een gevulde objectEindRegistratie heeft.
• Geef deze als beginGeldigheid: de eindGeldigheid van het laatste versie uit de (LV)BGT (die een objectEindtijd heeft).
• Geef deze als eindGeldigheid: leeg
• Geef deze als beginRegistratie (BH): de eindRegistratie van het laatste versie uit de (LV)BGT (die een objectEindtijd heeft)
• Geef deze als eindRegistratie (BH): leeg
• Geef deze als beginRegistratie (LV): publicatiedatum van het voorliggende voorkomen.
• Geef deze als eindRegistratie (LV): leeg
• Pas de vertaalspecificatie voor IM Gebouw 'status' toe

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

• Zie: IMGeo-Object tijdstipRegistratie (8.1.4)
• Bv. voorkomen 1, IMGeo-Object tijdstipRegistratie 2-1-2021 (ingewonnen op 1-1, maar geregistreerd op 2-1).
• Dit wordt in IM Gebouw, voorkomen 1: zit nu niet in IM Gebouw.
• Kan eventueel als bonus gegeven worden opgenomen in de API, dan: ‘tijdstip registratie authentieke bron’ is 2-1-2021

Gewenst gegeven: eindRegistratie Bronhouder van een versie van een object

• Zie: IMGeo-Object eindRegistratie (8.1.5)
• Bv. voorkomen 1, IMGeo-Object eindRegistratie 2-3-2021
• Dit wordt in IM Gebouw, voorkomen 1: zit nu niet in IM Gebouw.
• Kan eventueel als bonus gegeven worden opgenomen in de API, dan: ‘eind registratie authentieke bron’ is 2-3-2021

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.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.2 Aanbevelingen

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:

• Een van bovenstaande 4 items (vermoedelijk 2)
• Vertaalregels, deze bestaan uit:
  • Directe eigenschappen, te vinden in § 11. Gebouwen van bron naar SOR
  • Historie BAG en BGT, te vinden in § 12. Specificatie van de vertaling van historie
  • Metadata

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.1 Onderzoeksvragen

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

• Is het SOR Gebouw model MVP te implementeren; waar loop je tegenaan?
• Zijn de transponeringsregels te implementeren; waar loop je tegenaan?

15.2 Opzet

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:

• Een Lookup API SOR Gebouw, conform het informatiemodel uit § 8. IMSOR Gebouw. Deze API ondersteunt het gehele informatiemodel en regelt de orchestratie van BAG en BGT naar SOR. De REST API, URI Dereferencing service, en OGC Features API worden hier bovenop gebouwd. Het SPARQL Endpoint maakt voor deze High-5 gebruik van de URI Dereferencing service voor het vullen van de onderliggende aspect-database. De Lookup API is geen voorziening voor eindgebruikers.
• Een REST API voor de grote groep gebruikers die gegevens nodig heeft voor administratieve processen. De REST API ondersteunt vragen over gebouwen en geeft JSON terug. Deze API ondersteunt collecties met paginering, en heeft een endpoint voor individuele bevraging. Heeft ook CRS negotiation; de default is ETRS 89. Levert HAL JSON, compliant met NL API strategie. Geen JSON-LD (die zit wel in de URI dereferencing service). We maken gebruik van REST tooling om te laten zien dat het werkt.
• Een URI Dereferencing service die op basis van de URI identifier van een object de gegevens teruggeeft als RDF in gebruikelijke formaten zoals Turtle, JSON-LD en meer.
• Een OGC API Features (part 1) API die ruimtelijke vragen ondersteunt en GeoJSON en HTML ondersteunt. Deze API is voornamelijk bedoeld voor de gebruikers die de data willen gebruiken in GIS software. We realiseren een client GIS viewer om te laten zien dat het werkt.
• Een Linked Data API (SPARQL endpoint) bovenop een knowledge graph plus een data story om te laten zien dat het werkt. Deze voorziening is voor data scientists / business analisten en dergelijken.

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.

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

... maar moeten uiteindelijk een apart onderdeel worden 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.

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:

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

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.

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.

16.1 Bevindingen over het informatiemodel

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