Omdat het hier een standaard betreft die voor alle diensten van het Kadaster geldt, zou ik verwachten dat deze standaard ALLE mutatie types die er kunnen optreden binnen de diensten van het Kadaster worden beschreven. Dat sommige mutatie types op dit moment slechts door één dienst wordt gebruikt, vind ik geen reden om dan maar geen beschrijving voor dat mutatie type op te nemen. In de toekomst kan het zijn dat andere diensten ook deze mutatie types gaan ondersteunen. Als deze mutatie types dan niet in deze standaard zijn beschreven, dan lopen we het risico, dat die dienst een mutatie verwerking kiest die niet overeenkomt met de dienst die het tot dan toe al wel implementeerde. Het gevolg is inconsistentie en met een standaard proberen we nu juist consistentie en uniformiteit te waarborgen. Dat er uitzonderlijke mutatie types zijn beschreven, wil niet zeggen dat alle diensten ook alle mutatie types moeten ondersteunen, dat kan per dienst verschillen. Zie het KHM v4 als een soort menukaart. Kortom, de standaard moet zonder uitzonderingen alle mogelijke mutatie types beschrijven die er in alle diensten van het Kadaster voorkomen.

Als een object wordt beëindigd (bv. een pand wordt gesloopt), dan is de nieuwe toestand van het pand 'pand gesloopt' en dat blijft ook zo. Het volstaat dus niet altijd om alleen een tijdstip eind registratie in te vullen, er ontstaat ook een nieuwe toestand en een voorkomen zonder eind geldigheid en eind registratie met de nieuwe status 'pand gesloopt'. Overigens is het ook afhankelijk wat er wordt bedoeld met tijdstip eind registratie of zoals het hier staat: "De registratie van het object krijgt een eindtijdstip." Als het tijdstip eind registratie bedoeld is om aan te geven wanneer een voorkomen een eind geldigheid heeft gekregen (wat volgens mij het idee is: iets veranderd in werkelijkheid en dat wordt geregistreerd), dan kan er dus niet alleen een tijdstip eind registratie worden ingevuld zonder een eind geldigheid in te vullen.

Ik vind veel van de zaken die nu in bijlagen staan wel dermate relevant dat ze in een hoofdstuk zouden moeten staan.

gebruik

hier

correctiedocumenten

Anders gezegd: zolang de lokale database van bv KOERS, BAG, BGT etc. leidend is, worden TTO of TTV (of TTC, TTIA) aan de data hub doorgegeven als transactie tijdstip in de mutatie interface. Het transactie tijdstip wordt gebruikt om TTI en TTA in de data hub te zetten. Zodra de data hub de leidende database wordt (bv. zodra BAG rechtstreeks in de data hub muteert en geen eigen database meer bijhoudt), dan wordt er geen TTO, TTV etc. meer als transactie tijdstip meegegeven en bepaald de data hub database zelf het tijdstip waarop een record wordt geinsert in de database (TTI) en welk voorkomen wordt afgesloten (TTA). Bij een synchronisatie, correctie of intrekking wordt ook gebruik gemaakt van het mutatie type zodat TTC of TTIA gezet kan worden. Dit is handig voor de migratie van een registratie of lv naar de data hub.

Ik mis beschrijvingen voor de scenario's: - herleven van een object - intrekken van een toekomstig voorkomen

Ik mis beschrijvingen voor de scenario's: - herleven van een object - intrekken van een toekomstig voorkomen

Welk voorbeeld betreft het hier?

Bij sommige registratie (zoals bv. BGT) wordt formele levensduur bijgehouden. De betekenis van dit begrip is anders in NEN 3610:2011 en NEN 3610:2022. Het doel van formele levensduur is, dat ongeacht welk voorkomen je opvraagt, dat je altijd kunt zien van wanneer tot wanneer een object bestond/bestaat. Daarbij wordt per voorkomen een object begin tijd en een object eind tijd bijgehouden. De object eind tijd wordt bij het beëindigen van het object ingevuld in alle voorkomens van het object (althans in NEN 3610:2011, maar niet in NEN 3610:2022 wat volgens mij fout is in NEN 3610:2022, omdat je dan het doel niet bereikt). Stel dat er nu meer dan 2 voorkomens zijn: hoe worden de object eind tijd dan in historische (niet actuele) voorkomens gezet? Gebeurt dat met een correctie? Dit is een verschil tussen NEN 3610 en het KHM, moet deze ook in dit document worden beschreven? M.i. wel.

Waarom is dit een bijlage? Het lijkt me vrij relevant om historie correct en consistent te modelleren, omdat uit het informatiemodel het MIM model voor de data hub wordt gegenereerd. Data hub gebruikt het MIM model om een tenant te genereren inclusief API's met tijdreis functionaliteit.

Waarom? Het kan uiteraard wel, maar een koppeltabel is eigenlijk alleen noodzakelijk bij een n:n relatie. Bij een 1:n relatie volstaat het om in een database de relatie in de tabel bij het object of gegevensgroep aan de n kant op te slaan ook al ligt de relatie van de 1 naar de n kant. Worden 1:n relaties in de data hub ook gerealiseerd met een koppeltabel of komt daar de relatie ook in de tabel aan de n kant te staan?

Ik vind deze (en de volgende) bijlage(n) wat lastig te lezen en volgens mij staan hier dingen dubbel in t.o.v. van eerdere hoofdstukken. Ik denk dat het zou helpen als er beschreven wordt wat het scenario betreft, bv. Toevoegen, Wijzigen etc. omdat ze dan makkelijker te vergelijken zijn met paragrafen 3.2 en 3.3. Wat is het verschil met de scenario's in 3.2 en 3.3? En waarom is er dan ook nog een bijlage C? Kan e.e.a. niet beter worden samengevoegd per scenario (bv. Toevoegen) en daar voor KHM beschrijven hoe het werkt en daarna de verschillen met NEN3610 en StUF uitleggen?

Dit is vergelijkbaar met het intrekken van een toekomstige mutatie. Ook hier zal het voorkomen een tijdstip krijgen vanaf wanneer het voorkomen niet meer tot de actieve levenscyclus van een object behoort en zal ook het daaraan voorafgaande voorkomen ingetrokken moeten worden omdat dat voorkomen de nieuwe actuele toestand wordt maar dan zonder LTV, TTV, TTA etc. Eigenlijk betreft het hier (en bij het intrekken van een toekomstige mutatie) dus een mutatie type INTREKKING.

Ik begrijp niet wat hiermee wordt bedoeld. Een object heeft een eind status (beëindigd=true) of niet (beëindigd=false). Hoe en wanneer beëindigd true of false wordt bij iedere dienst, is toch aan die dienst en niet iets generieks?

Is feitelijk een reguliere wijziging met een bijzonder tintje omdat de status veranderd van een eind status (beëindigd=true) naar een niet eind status (beëindigd = false).

Waarom heeft RID:7 geen gebruiksdoel? Het enige wat er verandert t.o.v. de vorige versie is dat het object van een niet eind status naar een eind status gaat. In die zin is een beëindiging een reguliere wijziging, maar wel met een bijzonder tintje.

Voor de leesbaarheid zou ik de gegevens die bij elkaar horen steeds naast elkaar zetten, dus bv. LTO, LTV, TTO, TTV. Ook zou ik TTC achter TTI en TTA zetten, omdat TTI en TTA vaker gebruikt worden dan TTC.

Is dit dan geen principe of requirement o.i.d. die apart benoemd moet worden?

Ook lookup API en bulk APi benoemen omdat deze de tijdreis vragen implementeren?

mag weg

Ook meerdere verschillende mutatietypes?

Deze zin loopt niet lekker.

I tabel

Misschien ook even uitleggen hoe dat werkt bij 1:n relaties tussen gegevensgroepen onderling of tussen gegevensgroep en object. Bij 1:n relaties wordt er voor de gegevensgroep aan de n kant in de data hub bv. een aparte tabel gemaakt. In dat geval leg je wel een relatie tussen een gegevensgroep (record) en een versie (voorkomen) van een object.

I- tabel

I- tabel

complex

Waarom staat LTV wel en TTV niet in deze tabel?

Willen we hier nog iets voorschrijven over de waarde van versie voor het eerste voorkomen van een object? Deze zou 0 mogen zijn, maar ik denk dat het handiger is om altijd bij 1 te beginnen, omdat dit voor niet technische mensen begrijpelijker is. Het eerste voorkomen heeft versie 1 i.p.v. 0.

TTIA ontbreekt

Als gegevens gecorrigeerd zijn, is het oude voorkomen ook inactief. TTIA duidt erop dat een toekomstig voorkomen is ingetrokken. waardoor het 'oude' voorkomen inactief is geworden. Misschien is het daarom beter om het niet inactief maar ingetrokken toekomstig voorkomen te noemen.

zinnen lopen niet en volgens mij staat hier 2x hetzelfde. combineren?

Betreffen tijdstip registratie en eind registratie hier de registratie bij Kadaster of die bij een bronhouder? Volgens mij is dat afhankelijk van of het een registratie bv. BRK of een LV bv. BAG betreft. Aangezien tijdstip registratie en eind registratie in de kolom NEN 3610 staat en NEN 3610 volgens de alinea hierboven een uitwisselingsformaat is, zou ik verwachten dat dit de tijdstippen zijn van registratie bij een bronhouder en dat betekent dat deze mapping niet juist is, althans niet voor een LV, voor een registratie als BRK misschien wel. Het gaat er volgens mij om dat het tijdstip registratie en eind registratie bij het Kadaster is. Bij een LV worden deze tijden nl. aangeleverd en betekenen dan het tijdstip registratie bij een bronhouder. In dat geval bepaalt de LV zelf bv. tijdstip registratie LV en eind registratie LV als moment waarop Kadaster de gegevens heeft geregistreerd. In dat geval geldt tijdstip registratie LV=TTO en eind registratie LV=TTV. Tijdstip registratie en eind registratie zijn dan weliswaar meta gegevens maar worden door de LV verder behandelt als gewone gegevens net als bv. gebruiksdoel, bouwjaar of status.

gegeven (enkelvoud)

inwerkingtreding

Eigenlijk alleen TTI. TTA is een uitzondering, die wordt met een update toegevoegd aan een bestaand record.

bedoelt

Waarom niet? Kadaster kan deze toch zelf 'reconstrueren' en opslaan? Wat opgeslagen is, kan ook worden uitgeleverd.

Ik mis in paragraaf 3.3 voorbeelden van de scenario's: - herleven object - intrekken toekomstig object voorkomen

Is het brondocument wel onderdeel van de audittrail? Is deze niet onderdeel van het Voorkomen? Het is immers informatie die wordt aangeleverd? Een audittrail is typisch informatie die we als Kadaster zelf bepalen en vastleggen. Dat we ervoor (kunnen) kiezen om zelf het brondocument als treansactiedocument te gebruiken is een implementatie kwestie.

Het TTO is verplicht en moet multiplicity 1 hebben i.p.v. [0..1]. Ieder voorkomen wordt immers op een bepaald moment vastgelegd (technisch tijdstip ontstaan). Een andere reden is dat dit tijdstip nodig is voor het correct beantwoorden van tijdreisvragen. De tijdreisparameter 'beschikbaarOp' heeft betrekking op de registratie tijdslijn. Als een TTO ontbreekt in een voorkomen dan matcht het tijdstip beschikbaarOp op een eerder voorkomen dat wel een TTO (maar geen TTV) heeft of als een eerder voorkomen wel een TTO en TTV heeft en de TTV is eerder dan beschikbaarOp dan matcht geen enkel voorkomen en dat klopt theoretisch niet als er daarna nog andere voorkomens zijn. Ter vergelijking zie tijdstip registratie in NEN 3610, deze is ook verplicht. Daarnaast mis ik hier TTIA. Ik vraag me af of TTC en TTIA niet ook onderdeel van Registratie moeten zijn. Ik denk dat dit in paragraaf 3.1.1 beschreven moet worden.

ontwikkeld

Mag weg

Hier geldt dat TID 3 moet zijn van RID:5.

Hier geldt dat het TID 2 moet zijn van RID:3.

M.i. moeten de tijdreis regels in 3.2.5 worden aangepast / uitgebreid zodat er ook naar TTC en TTIA wordt gekeken. Waarom? Een TTV (TTA) markeert het moment van registratie van het normaal afsluiten van een geldigheidsperiode (voorkomen). Het voorkomen blijft onderdeel van de actieve levenscyclus. Een TTC markeert het moment van registratie van het corrigeren van een voorkomen maar niet van het afsluiten van de geldigheidsperiode van dat voorkomen omdat het voorkomen niet wordt opgevolgd maar vervangen door een ander voorkomen. Een TTIA markeert het moment van registratie van het intrekken van een toekomstig voorkomen (en evt. voorgaand voorkomen), maar niet van het afsluiten van de geldigheidsperiode van dat voorkomen omdat dit voorkomen (en een evt. voorgaand voorkomen) niet wordt opgevolgd maar vervangen door een ander voorkomen. In die zin kunnen TTC en TTIA worden gezien als een alternatief eind tijdstip waardoor een voorkomen geen deel meer uitmaakt van de actieve levenscyclus maar nog wel van de inactieve levenscyclus. TTV wordt gezien als het eind tijdstip waarmee een voorkomen wel wordt beëindigd en nog onderdeel blijft uitmaken van de actieve levenscyclus. Daarom mag bij het zetten van TTC en TTIA ook alleen volgens specifieke regels een LTV en TTV worden ingevuld. De LTV mag alleen worden overgenomen als deze al in het bestaande gecorrigeerde voorkomen stond, de TTO en TTV mogen nooit worden overgenomen van een bestaand gecorrigeerd voorkomen en moeten altijd het tijdstip krijgen waarop het nieuwe voorkomen is ontstaan en/of vervallen. TTO van het nieuwe vervangende voorkomen wordt dan gelijk aan TTC. Als een bestaand gecorrigeerd voorkomen een TTV had, dan krijgt het nieuwe vervangende voorkomen een nieuwe TTV gelijk aan TTC. Bij TTIA ligt dat wat ingewikkelder, daar krijgt het vervangende voorkomen een TTO gelijk aan TTIA van het bestaande toekomstige voorkomen (en evt. daaraan voorafgaande voorkomen) en geen LTV en TTV als het toekomstige voorkomen geen LTV en TTV heeft. Als het toekomstige voorkomen zelf ook al gemuteerd is (er is dus een nog nieuwere toekomstige mutatie), dan moeten alle toekomstige mutaties van nieuwste naar oudste worden ingetrokken. Het vervangende voorkomen is dan het actuele voorkomen zonder LTV en TTV.

Volgens mij klopt dit niet. RID:5 ontstaat door de correctie en wordt dus geregistreerd op moment TTC en niet op moment TTO van RID:4. Door de TTO gelijk te maken aan het TTC kun je (beter) zien dat het record is ontstaan door de correctie.

In het record met RID:4 is LTV gezet, dat klopt niet want er komt geen volgend record, maar een vervangend record. Bovendien moet TTV gezet worden als een LTV gezet wordt. TTV is nl. het moment waarop een eind geldigheid wordt geregistreerd.

moet woonfunctie zijn, zo staat het in de tabel en bij correctie in de volgende paragraaf wordt het logiesfunctie.

Ook hier geldt dat het transaction ID 1 i.p.v. 2 moet zijn van het record met RID=1.

mag weg

kunnen

heden?

gebruiksdoel

Een voorkomen ID (VID) zoals deze in dit document wordt beschreven is eigenlijk geen identificatie van een voorkomen van een object, omdat het een voorkomen niet uniek identificeert in de tijd gezien. Als je de VID in een REST endpoint zou gebruiken bv /panden/0200100000085932/1 dan zou het kunnen zijn dat het antwoord op dezelfde vraag in de loop van de tijd een ander antwoord geeft. Dit kan bv. door correctie of synchronisatie veroorzaakt worden. Met de hier beschreven methodiek krijg je nl. altijd de meest recente versie van een voorkomen met (in dit voorbeeld) voorkomen ID 1.

Is dat zo? Zo ja, waarom is dat zo? Uitleggen a.d.h.v. een voorbeeld?

Mag een mutatie zonder brondocument worden doorgevoerd? Oftewel moet een brondocument niet verplicht zijn in het metamodel hieronder?

beschrijft

Voor REST API's is dit wel nodig. Daarbij levert bv. een endpoint /panden/0200100000085932 alle voorkomens van het pand object en bv. /panden/0200100000085932/1 het eerste voorkomen van dat pand. Als het voorkomen geen identificatie krijgt, dan wordt het veel lastiger (of zelfs onmogelijk) om een specifiek voorkomen op te vragen, terwijl dat bij REST wel de bedoeling is. Ik wil daarom adviseren een voorkomen identificatie verplicht te maken.

Ik denk dat het handig is om te definiëren wat een transactie is en wat een mutatie is en de verhouding daartussen. Volgens mij is een transactie de uitwisseling van informatie tussen twee partijen en kan het gevolg daarvan zijn dat er meerdere mutaties plaatsvinden op één of meer objecten. Is het dan ook mogelijk dat één transactie meerdere mutaties van verschillende mutatie types tot gevolg heeft? Dat wordt hier m.i. niet helemaal duidelijk.

Aanvullend daarop: om een vergelijking te trekken met state transition diagrammen: in een state transitie diagramm is een transitie een verandering (transitie) van een systeem van één toestand (state) naar een andere toestand. Deze verandering wordt veroorzaakt (getriggered) door een gebeurtenis (event). De toestand (state) is te vergelijken met een voorkomen van een object (systeem) die muteert (transitie) door een transactie (event).

Ondanks dat het KHM qua definities overeenkomt met NEN3610 zou het denk ik goed zijn om in hoofdstuk 4 ook lijsten met termen en afkortingen op te nemen.

gebruiksdoel

overbodig

Wat hier m.i. niet helemaal duidelijk naar voren komt is dat het hier gaat om het tijdstip waarop mutaties worden verwerkt in de registratie bij Kadaster. Dat is het enige waarover Kadaster iets kan zeggen m.b.t. tijdreizen met (o.a.) beschikbaarOp. Bij landelijke voorzieningen (bv. BAG en WOZ) is er ook een registratie bij bronhouders, maar die is voor historie opbouw en tijdreizen met geldigOp en beschikbaarOp niet relevant maar wordt wel opgeslagen. In het kader van tijdstip registratie en tijdstip eind registratie (NEN3610) gaat het dus om Kadaster registratie momenten en niet om de registratie momenten bij bronhouders! Het lijkt mij goed om dit toe te voegen.

Vraag: geldt dit voor alle registraties en landelijke voorzieningen? Als dat nl. niet zo is, dan matchen de begrippen geldigheid en registratie tijdlijn mogelijk niet voor die registratie of lv.

Dit komt m.i. niet overeen met war er in 2.3.1 punt 3 staat. Wat hier staat is volgens mij correct.

Voor synchronisatie wordt hetzelfde tijdstip (TTC) gebruikt om aan te geven dat een voorkomen is gecorrigeerd en vervangen door iets nieuws. Dit geldt normaal alleen voor historische (niet actuele) voorkomens, want als het een correctie van een actueel voorkomen is, dan is het een reguliere wijziging. Bij een synchronisatie wordt echter ook het actuele voorkomen 'gecorrigeerd' i.p.v. gewijzigd.

Hier ontstaat het risico dat er geen onderscheid gemaakt kan worden door een correctie die d.m.v. een synchronisatie is doorgevoerd of door een afzonderlijke 'correctie' mutatie.

Zoals het hier staat is het een reguliere wijziging. Wanneer is iets een correctie en geen wijziging? Volgens mij is dat het geval als er in het brondocument iets anders staat dan wat er is geregistreerd. Het actuele voorkomen 'corrigeren' kan dan met een reguliere wijziging of een correctie maar dat is afhankelijk van de registratie. Verder mis ik hier een correctie in het verleden. Dat betekent dat de historie zoals die tot het moment van corrigeren beschikbaar was, blijft bestaan, maar dat er een wijziging wordt gedaan van een historische voorkomen, waardoor een nieuwe revisie van een versie ontstaat en de bestaande revisie een 'gecorrigeerd' tijdstip krijgt en waarbij de toestand zoals beschreven in een brondocument wordt doorgevoerd.

Hier ontstaat het risico dat de ene dienst een reguliere 'wijziging' mutatie type gebruikt voor een correctie en een andere dienst een 'correctie'.

Dit is één situatie waarbij de 'werkelijkheid' al veranderd is en waarbij de geldigheid eigenlijk later is dan de werkelijkheid. De uitbouw wordt hier geconstateerd en er wordt een brondocument voor opgemaakt nadat deze situatie is gerealiseerd. Een andere situatie is dat er eerst een brondocument is bv. als een pand gesloopt mag worden, dan is het brondocument er eerder (en de registratie mogelijk ook) dan de werkelijke toestand 'pand gesloopt'. De geldigheid tijdlijn is dus een benadering van de werkelijkheid, maar kan hierop voor- of achterlopen. Eigenlijk betreft de geldigheid tijdlijn dus niet de werkelijkheid maar het moment waarop er in een brondocument een formeel besluit is genomen over een toestand. Ik vind persoonlijk dat dit wel duidelijker beschreven mag worden.

'in' ontbreekt.

Als een object een (formele) levensduur heeft conform NEN 3610, dus het object heeft een object begin tijd en object eind tijd, hoe worden deze dan gevuld bij het beëindigen en herleven van een object? Welke consequenties heeft het dat object begin tijd en object eind tijd in NEN 3610:2022 t.o.v. NEN3610:2011 een andere betekenis hebben gekregen?

Het zogenaamde herleven van objecten is een scenario wat ondersteund moet kunnen worden. Als er bv. per ongeluk een eind status is opgegeven (bv. pand gesloopt) dan verandert het attribuut beëindigd van false naar true. Bij herstel van deze fout 'herleeft' het object van een eind status naar een niet eind status en verandert beëindigd van true naar false. Beëindigd is dus bedoeld om aan te geven of het object één van de eind statussen heeft, het object is ook met een eind status nog gewoon geldig. Wat de exacte status is staat in een status attribuut. Beëindigd is absoluut niet hetzelfde als een datum eind geldigheid, omdat een datum eind geldigheid alleen het einde van een geldigheidsperiode aangeeft (ook wel voorkomen of versie genoemd). Na dit voorkomen kan een ander geldig voorkomen bestaan die eveneens geldig is.Zie ook NEN 3610 begin geldigheid en eind geldigheid. Die gegevens zeggen niets over of een object een eind toestand (volgens een state transitie diagram) heeft bereikt.

Mutatie type 'intrekken toekomstig voorkomen' ontbreekt hier, terwijl verderop in het document het tijdstip TTIA (Technisch Tijdstip InActief) wel wordt genoemd.