Tijd

In registers komen we veel soorten tijd tegen: passeerdata, looptijden, ontvangstmomenten, bouwjaren. Maar als we het hebben over tijd in registers noemen we meestal slechts twee tijdsdimensies: een aan het domein ontleende geldigheidstijd en een door het systeem toegekende systeemtijd.

Deze dichotomie is te overbruggen door onderscheid te maken tussen tijd ín de bewering en tijd ván de bewering.

Tijd ín de bewering noemen we domeintijd. Binnen een bounded context kunnen allerlei soorten domeintijd voorkomen: een passeerdatum, een bouwjaar of een ontvangstmoment. Net als een naam of een adres beschouwen we domeintijd als gegeven.

Tijd ván de bewering valt uiteen in werkingstijd en systeemtijd. Deze plaatsen de bewering zelf in de tijd, en vormen zo de datering van een bewering.

Domeintijd, werkingstijd en systeemtijd

Domeintijd is een gegeven in de inhoud van een bewering, dat een moment of periode uit het domein vastlegt: een bouwjaar van een pand, peildatum voor de waarde van een WOZ-object, of de periode dat iemand voor een opleiding is ingeschreven. Betekenis, vorm en waarde van zulke tijdsgegevens worden bepaald door het vastleggende domein en beschreven in het bounded contextmodel en daarbinnen voorkomende gegevenssoorten. Daardoor kan een bewering van nul tot een oneindig aantal domeintijdstijdsgegevens bevatten. Registers verwerken tijdsgegevens niet anders dan 'gewone' gegevens. Dit betekent dat inwerkingsregels nodig zijn om domeintijdsgegevens geautomatiseerd te kunnen verwerken.

Domeintijd definiëren we als "gegeven dat een moment of periode aanduidt, in de vorm die in een gegevenssoort is beschreven".

De waarde van werkingstijd wordt weliswaar ontleend aan domeintijd, maar functie en karakter verschillen wezenlijk. Werkingstijd is geen gegeven in de inhoud, maar een tijdskenmerk van de bewering zelf. Dit kenmerk geeft, in ieder domein op dezelfde manier, aan wanneer de toestand geldt of het gebeuren plaatsvindt dat de bewering beschrijft, en dateert de bewering zo op de tijdlijn van het domein. Waarop de werkingstijd betrekking heeft, hangt af van wat de bewering zegt, ofwel het predicaat daarvan: bij 'p1 staat ingeschreven op a1' is de werkingstijd de periode waarin de inschrijving geldt, bij 'p1 woont feitelijk op a1' de periode van feitelijk wonen, bij 'p1 is verhuisd' het moment waarop de verhuizing plaatsvond. Deze voorbeelden laten ook zien dat de vorm van de werkingstijd afhangt van wat een bewering beschrijft: een moment bij een gebeurtenis, een periode bij een traject, en bij een toestand één of meer periodes. Maar ook als er sprake is van meerdere periodes, liggen die allemaal op dezelfde tijdlijn en vormen samen één werkingstijd; meer dan één werkingstijd kan een bewering niet hebben. Omdat betekenis en vorm in elk domein gelijk zijn, kan het register zonder domeinkennis met werkingstijd werken, bijvoorbeeld om te selecteren wat op een peilmoment gold of om aansluitende periodes samen te voegen.

Werkingstijd definiëren we als "tijdskenmerk dat aanduidt wanneer de toestand die een bewering beschrijft geacht wordt te gelden, dan wel het gebeuren dat de bewering beschrijft geacht wordt zich te voltrekken".

Net als werkingstijd is systeemtijd een tijdskenmerk van de bewering zelf. Dit kenmerk dateert de bewering echter niet in het domein, maar op de tijdlijn van het systeem dat de bewering voortbrengt. Systeemtijd is altijd een moment, met steeds dezelfde betekenis, ongeacht wat de bewering beschrijft of in welk register die wordt bijgehouden. Net als bij werkingstijd kan het register daarom zonder domeinkennis met systeemtijd werken, bijvoorbeeld om beweringen op volgorde te zetten, te selecteren wat op een peilmoment werd onderschreven of te bepalen welke bewering een eerdere opvolgt. Iedere bewering heeft precies één systeemtijd. Het systeem bepaalt de waarde, en ook welk technisch moment als voortbrengen geldt (zie Systeemtijd). Systeemtijd kan de waarde leveren voor een domeintijdsgegeven. Neem de beweringssoort 'persoon is per inschrijvingsmoment ingeschreven op adres': het domein bepaalt dat het inschrijvingsmoment ertoe doet, maar kan ervoor kiezen de waarde daarvan bij concrete beweringen van deze soort aan de systeemtijd te ontlenen.

Systeemtijd definiëren we als "tijdskenmerk dat aanduidt wanneer een bewering door een systeem is voortgebracht".

Onderstaande tabel toont overeenkomsten en verschillen tussen de drie soorten tijd:

	Domeintijd	Werkingstijd	Systeemtijd
Karakter	gegeven in de inhoud van de bewering	tijdskenmerk van de bewering	tijdskenmerk van de bewering
Functie	legt een moment of periode uit het domein vast	dateert de bewering op de tijdlijn van het domein	dateert de bewering op de tijdlijn van het systeem
Betekenis	domeinspecifiek, ontleend aan het bounded contextmodel	over alle domeinen hetzelfde: wanneer een toestand geldt of een gebeuren zich voltrekt; waarop de werkingstijd betrekking heeft, hangt af van het predicaat van de beweringssoort	over alle domeinen hetzelfde: het moment van voortbrengen
Vorm	beschreven in de gegevenssoort	een moment of één of meer periodes, afhankelijk van wat de bewering beschrijft (een gebeurtenis, traject of toestand)	altijd een moment
Verwerking vereist	domeinspecifieke inwerkingsregel	geen domeinkennis	geen domeinkennis
Waarde komt uit	het domein of systeemtijd	domeintijd	het systeem
Aantal per bewering	0..n	0..1	1

Domeintijd is beweringsinhoud en wordt door het register behandeld als een 'gewoon' gegeven dat onderdeel is van het bounded contextmodel. Het betrouwbaarheidsaspect tijd is met name gericht op datering. De rest van dit hoofdstuk werkt daarom werkingstijd en systeemtijd verder uit, en volgt daarna de tijd door het register heen.

Vormen van werkingstijd

Werkingstijd kent twee vormen, ieder gekoppeld aan een type bewering: geldigheid bij een bewering over een toestand en voltrekking bij een bewering over een gebeuren. Dit onderscheid is gebaseerd op de temporele vraag die je over ieder van deze beweringstypes kunt stellen. Omdat een toestand op ieder moment binnen de periode 'geldt', kan je daarover een geldigheidsvraag stellen. Een gebeuren voltrekt zich daarentegen van begin tot voltooiing: bij een traject liggen die uit elkaar en is het gebeuren pas voltooid aan het einde van de periode die het traject beslaat, bij een gebeurtenis vallen ze samen op één moment. Daarover stel je een voltrekkingsvraag: is het binnen een periode begonnen, voltooid of gebeurd?

Geldigheid

Geldigheid is de werkingstijd van een toestand: de periode waarin de toestand die een bewering beschrijft, geacht wordt te gelden. Binnen die periode geldt de toestand op elk moment. Een toestand is daarom op elk moment te bevragen (geldigOp, geldigVanaf, geldigTot), en twee aansluitende periodes van dezelfde toestand vormen samen één periode.

Geldigheid wordt uitgedrukt in een geldigheidsperiode, met een begin en een mogelijk nog open einde. Een open einde betekent dat de toestand voor zover bekend nog geldt, niet dat die voor altijd geldt. Is het einde van de geldigheid op voorhand bepaald, zoals bij een vergunning met een vastgestelde looptijd, dan is de periode niet open, maar heeft die een einde in de toekomst, dat al vanaf het begin deel uitmaakt van de werkingstijd (zie Werkingstijd in de toekomst).

Of er één of meer geldigheidsperiodes zijn, hangt af van het type toestand dat een bewering beschrijft: eenmalig of herlevend. Een eenmalige toestand heeft één geldigheidsperiode. Een herlevende toestand kan er meerdere hebben, gescheiden door een onderbreking. Een vergunning die wordt geschorst en na afloop van de schorsing weer in werking is, herleeft: het is dezelfde vergunning, die een tijd niet gold maar desondanks één werkingstijd kent, die meer dan één periode omvat. Voor afnemers is het belangrijk te weten of een toestand kan herleven, want dan moet die met meerdere geldigheidsperiodes kunnen omgaan.

Of een toestand in het register daadwerkelijk moet kunnen herleven, is een modelleringskeuze. Zo kan herleven van de vergunning worden voorkomen door de schorsingsperiode als domeintijd in de inhoud vast te leggen, en het bijbehorende gedrag te beschrijven in inwerkingsregels.

Misverstanden over geldigheid

In de praktijk wordt 'geldig' ook in andere betekenissen gebruikt, en dat leidt tot verwarring.

Geldig is niet hetzelfde als 'waar' of 'juist': literatuur spreekt in relatie tot geldigheid wel "van de tijd waarop een feit waar is", maar een register kan niet meer zeggen dan dat een toestand in een periode geacht wordt te gelden. Het onderwerp juistheid wordt verder besproken bij betrouwbaarheidsaspect zekerheid.

Geldig is niet hetzelfde als actueel: ook een toestand die vroeger gold, heeft een geldigheid.

Geldig is niet (altijd) hetzelfde als 'in werking': dat is het alleen als het predicaat van de bewering zegt dat iets in werking is. Bij 'besluit B is in werking' is de geldigheid de periode van werking, bij 'besluit B is onherroepelijk' een (waarschijnlijk kortere) andere periode.

Geldig is niet (altijd) hetzelfde als 'bestaand': dat is het alleen als het predicaat van de bewering iets zegt over het bestaan van een entiteit. Bij 'p1 leeft' is de geldigheid de periode dat p1 bestaat, bij 'p1 woont op a1' de periode van bewoning, en die zegt niets over hoe lang p1 of a1 bestaan. Temporele conceptuele modellen geven een entiteit vaak een levensduur (lifespan of existence time): de periode waarin die bestaat, waarbinnen alle kenmerken van de entiteit moeten vallen. Deze zienswijze leidt in de praktijk tot problemen, bijvoorbeeld als na het overlijden van een persoon geen nieuw adres meer kan worden vastgelegd, zoals een correspondentieadres voor de afwikkeling van de nalatenschap, terwijl nabestaanden daar wel bij gebaat zouden zijn. Omdat wij stellen dat een register geen entiteiten bijhoudt, maar beweringen erover, is zo'n levensduur bij ons geen kenmerk van de entiteit, maar de werkingstijd van één bepaalde toestandsbewering, zoals 'p1 leeft'. Of een adres daarbinnen moet vallen, is dan een regel die het register bij het optekenen kan toetsen, maar niet hoeft.

Deze verwarring wordt in de hand gewerkt doordat het predicaat van een toestandsbewering vaak niet zichtbaar is. Een registratie van panden toont meestal één rij per pand: 'pand q1, geldig vanaf …'. Welke datum daar staat, hangt af van het gebeuren waarmee de geldigheid begint. Is dat het verlenen van de omgevingsvergunning op 3 maart 2019, dan betekent geldig 'vergund'; is dat de gereedmelding van de bouw op 12 oktober 2021, dan 'gereed'; is dat de ingebruikname op 5 januari 2022, dan 'in gebruik'. Omdat de rij het pand vertegenwoordigt, ligt het voor de hand de geldigheid te lezen als het bestaan van het pand, maar die kan net zo goed betekenen dat het pand vergund, gereed of in gebruik is.

Hierboven staan drie verschillende beweringen, elk met een eigen werkingstijd: een juridisch, een administratief en een feitelijk perspectief op hetzelfde pand, die er niet altijd allemaal hoeven te zijn. Wie in een bewering over het gebruik toch wil vastleggen wanneer het pand vergund werd, neemt die datum op als gegeven: dan is het domeintijd in de inhoud, geen tweede werkingstijd (zie Van primaire bewering naar afgeleide bewering).

Door de beweringssoort een naam te geven die zegt wát er geldt, kunnen we duidelijker zijn over de betekenis van geldigheid bij toestandsbeweringen: 'staat ingeschreven op' of 'woont feitelijk op', in plaats van 'adres'. In een implementatie wordt een toestandsbewering echter vaak 'platgeslagen' in een tabelstructuur of resourcebeschrijving. De beweringssoort moet dan blijken uit de plek waar de beweringen staan: een tabel of resource per beweringssoort, met een naam die zegt wat er geldt ('inschrijvingen', niet 'adressen'). Staan beweringen van verschillende soorten in één tabel, dan noemt een kolom per rij de beweringssoort, bijvoorbeeld 'inschrijving' of 'feitelijke bewoning'. Hoe die betekenis aan afnemers wordt doorgegeven, beschrijft het hoofdstuk Betekenis.

Voltrekking

Voltrekking is de werkingstijd van een gebeuren: het moment of de periode waarin het gebeuren dat een bewering beschrijft, geacht wordt zich te voltrekken. Welke van de twee het is, hangt af van het type gebeuren. Een gebeurtenis heeft een voltrekkingsmoment, gebeurd op. Een traject heeft een voltrekkingsperiode, van het begin tot een voltooiing die nog niet bereikt hoeft te zijn: zolang die ontbreekt, loopt het traject voor zover bekend nog. Wie vraagt hoe een traject er op een bepaald moment voor stond, krijgt een opsomming van gepasseerde en lopende fases. Een gebeuren bevraag je daarom op voltrekking (gebeurdVanaf, gebeurdTot).

Misverstanden over voltrekking

Voltrekking correspondeert niet (altijd) met het begin van een geldigheid: dit punt heeft te maken met de omzetting van gebeurens naar toestanden. Neem de gebeurtenis 'p1 is op 1 mei naar a1 verhuisd', met 1 mei als voltrekkingsmoment. Daaruit zijn twee toestanden af te leiden. 'p1 woont feitelijk op a1', bijvoorbeeld voor huurtoeslag, neemt het voltrekkingsmoment als begin van de geldigheid, en geldt dus vanaf 1 mei. 'p1 staat ingeschreven op a1' doet dat niet: die gaat in de BRP vanwege beperkende regels pas op 5 mei in. Naast domeinregels bepalen ook modelleringskeuzes of geldigheid wordt afgeleid van de voltrekking of van een domeinmoment uit de inhoud van een gebeurenbewering (zie, voor de afleiding uit primaire beweringen Van primaire bewering naar afgeleide bewering).

Voltrekking is niet hetzelfde als registratie: voltrekking is het door het domein bepaalde moment of de periode waarin iets gebeurt, systeemtijd het moment waarop een systeem de bewering daarover voortbrengt. Een registratiemoment is een moment met een door het domein bepaalde betekenis. Dat moment kan samenvallen met de systeemtijd en daaraan worden ontleend (zie Domeintijd, werkingstijd en systeemtijd). Het kan ook samenvallen met de voltrekking, bij een administratieve formulering: in 'p1 is op 10 mei ingeschreven op a1' is de registratie zelf het gebeuren. En het kan een ander moment zijn, zoals het moment waarop een akte is opgemaakt die als bron dient.

Voltrekking kan niet worden bevraagd als ware het geldigheid: een toestandsbewering is waar op elk moment binnen de geldigheid, en is dus op elk moment te bevragen. Een bewering over een traject is alleen waar over de voltrekkingsperiode als geheel. De zinvolle vraag is daarom niet of het traject op een moment gold, maar of het binnen een periode is begonnen, voltooid of geheel verlopen.

Systeemtijd

Systeemtijd is het moment waarop een systeem een bewering voortbrengt. Elke bewering heeft er precies één, en die dateert de bewering op de tijdlijn van dat systeem.

"Het moment waarop een systeem een bewering voortbrengt" is bewust ruim geformuleerd. Technische overwegingen bepalen welke momenten hier gekozen kunnen worden. Zo ligt het moment van daadwerkelijke beschikbaarheid in het register voor de hand, maar dat moment is pas bekend als de bewering is vastgelegd, en dan is het te laat om het nog in de bewering op te nemen. Belangrijkste is dat een systeem één moment kiest, zodat systeemtijden onderling vergelijkbaar zijn, en dat afnemers weten welke betekenis dat moment heeft.

Veel temporele modellen onderscheiden een transactietijdlijn die loopt van invoegen tot (logisch) verwijderen (zie Tijd in andere kaders). Ons registerontwerp werkt anders: een bewering krijgt bij het voortbrengen een systeemtijd, maar geen eindmoment. Een periode ontstaat pas door een onttrekking, een andere bewering met een eigen systeemtijd. Uit die periode valt een vergelijkbare conclusie te trekken: wat het register in een bepaalde periode onderschreef.

Misverstanden over systeemtijd

Een bewering heeft niet meer dan één systeemtijd: elke bewering die een systeem voortbrengt, heeft één eigen systeemtijd, ook als die bewering op een andere is gebaseerd. Moet het moment van een eerdere schakel meereizen in de keten, bijvoorbeeld omdat een landelijke voorziening wil weten wanneer de bewering bij de bronhouder is voortgebracht, dan neemt de nieuwe bewering die waarde op als domeintijd. Een bewering die in een replicatie-, of mirrordatabase, cache of back-up wordt gedupliceerd, beschouwen we als gelijk aan het origineel. Die houdt daarom de oorspronkelijke systeemtijd (zie Nieuwe bewering of kopie?).

Het moment van verstrekken is geen systeemtijd: een verstrekking, zoals een notificatiebericht of een antwoordbericht, is geen bewering maar een drager daarvan. Een afgeleide bewering die pas bij het samenstellen van een verstrekking ontstaat, heeft wel een eigen systeemtijd, maar ook die hoeft niet samen te vallen met het moment van verstrekking.

Granulariteit

Elke tijdsaanduiding heeft een granulariteit: de korrel waarin de tijd wordt uitgedrukt, zoals een dag of een seconde. Dat geldt voor domeintijd, werkingstijd en systeemtijd. Bij domeintijd bepaalt het domein welke granulariteit past, en legt die vast in de gegevenssoort; een werkingstijd neemt de granulariteit over van de domeintijd waaraan die is ontleend. Een bouwjaar heeft als domeintijd de korrel van een jaar. Een geboorte wordt op de dag vastgelegd, een sensormeting op de seconde.

De granulariteit bepaalt of een gebeuren een gebeurtenis of een traject is. Een huwelijksvoltrekking is op de dag één moment, maar op de minuut een plechtigheid met een begin en een einde. Of iets op één moment plaatsvindt, het punt waarover Allen en Galton van mening verschillen (zie het kader in Typen beweringen), hangt in een register dus af van de korrel waarin het wordt vastgelegd.

Ook of twee periodes op elkaar aansluiten, hangt af van de granulariteit. Een geldigheid tot en met 30 april sluit op dagniveau aan op een geldigheid vanaf 1 mei; op het niveau van seconden ligt daar een nacht tussen, tenzij is afgesproken dat het einde van de ene periode het begin van de volgende is. Tijden met een verschillende granulariteit zijn daarom pas te vergelijken na omrekening, en die is niet altijd eenduidig: viel een gebeurtenis 'op 1 mei' vóór of na 1 mei om 14:00 uur?

Systeemtijd heeft de granulariteit die het systeem kiest, in de regel fijn genoeg om beweringen op volgorde te zetten.

Tijd door het register heen

Primaire bewering

Een primaire bewering beschrijft een gebeurtenis. De werkingstijd is dus een voltrekkingsmoment, het gebeurd op van de beschreven verandering. De systeemtijd is het moment van vastleggen in het journaal. Daarnaast kan een primaire bewering domeintijd bevatten, zoals een ingangsdatum.

Van primaire bewering naar afgeleide bewering

De projectiespecificatie bepaalt hoe de werkingstijd van een afgeleide bewering tot stand komt:

• door een domeinmoment uit de inhoud als werkingstijd te nemen, zoals een ingangsdatum;
• door het voltrekkingsmoment van een primaire bewering te nemen;
• of door de werkingstijden van meerdere onderliggende primaire beweringen te combineren.

Welke manier een projectie gebruikt, is een ontwerpafweging. Een verhuizing laat zien waarom. Iemand verhuist feitelijk op 1 mei, maar doet pas op 10 mei aangifte. De inschrijving in de BRP mag maximaal vijf dagen terugwerken, en gaat daarom in op 5 mei in plaats van 1 mei. Een projectie van de inschrijving kan het gebeurd op van de verhuizing dus niet als begin van de geldigheid nemen; een projectie van de feitelijke bewoning, bijvoorbeeld voor het toekennen van huurtoeslag, juist wel.

Neemt een projectie altijd het gebeurd op als begin van de geldigheid, dan kan het projecteren zonder domeinkennis. Daar staat tegenover dat elk perspectief een eigen primaire bewering nodig heeft: naast de feitelijke verhuizing een tweede gebeurtenis voor het ingaan van de inschrijving. Een projectie met een nieuw perspectief, waarvoor die primaire beweringen ontbreken, kan dan niet met terugwerkende kracht worden opgebouwd. Een toestand die pas in de toekomst ingaat, kan bovendien pas worden vastgelegd als die ingaat, omdat een gebeurd op nooit na de systeemtijd ligt.

Neemt een projectie het begin van de geldigheid uit domeintijd in de inhoud, dan is één primaire bewering genoeg: de verhuizing op 1 mei, met de ingangsdatum van de inschrijving als domeintijd. De projectie van de inschrijving neemt die ingangsdatum, de projectie van de feitelijke bewoning het gebeurd op, en later kan een projectie worden toegevoegd zolang de benodigde domeintijd in de inhoud staat. Daarvoor is wel domeinkennis nodig: een inwerkingsregel die zegt welke domeintijd de geldigheid begint.

Combineert een afgeleide bewering meerdere gegevens, dan is de werkingstijd de periode waarin al die gegevens samen gelden. Wanneer elk gegeven afzonderlijk inging, gaat daarbij verloren; is dat nodig, dan kan dat moment als domeintijd in de inhoud. Hetzelfde geldt voor een moment uit een ander perspectief.

De keuze tussen feitelijk en administratief formuleren werkt hierop door:

• Bij feitelijke formulering is het gebeurd-op-moment een logisch startpunt voor een geldigheidsperiode.
• Bij administratieve formulering ligt het gebeurd-op-moment dichter bij het moment van registratie, en staat het feitelijke moment als domeintijd in de inhoud.

Werkingstijd en domeintijd in een afgeleide bewering

De werkingstijd van een afgeleide bewering zegt wanneer die combinatie van gegevens geacht wordt te gelden, niet hoe oud de entiteiten of gegevens erin zijn. Data als 'geregistreerd sinds' of 'belanghebbend vanaf' zijn domeintijd. Een afnemer kan de werkingstijd dus makkelijk verkeerd lezen; de betekenis moet daarom duidelijk uit de afgeleide bewering blijken.

Een afgeleide bewering draagt zo alle drie de lagen: de systeemtijd van de eigen voortbrenging, de werkingstijd die de projectie toekent, en de domeintijd uit de inhoud. Wanneer een toestand eindigt, blijkt uit een volgende bewering in de reeks (zie Projecties opbouwen).

Werkingstijd in de toekomst

Een register legt alleen vast wat al gebeurd is. Het gebeurd-op-moment van een primaire bewering ligt daarom nooit na de systeemtijd, en een uitspraak als 'P gaat volgende week verhuizen' kan geen primaire bewering zijn.

Wel kan een register vastleggen dat er nu iets gebeurt dat naar de toekomst verwijst, zoals een aangifte, een besluit of een voornemen. Dat gebeuren is de primaire bewering, met een voltrekkingsmoment van nu; het toekomstige moment staat erin als domeintijd. Een verhuizing kan bijvoorbeeld vanaf vier weken vooraf bij de gemeente worden aangegeven. De primaire bewering is dan 'P heeft op 3 november aangegeven op 1 december naar A te verhuizen', met 1 december als domeintijd.

Een afgeleide bewering kan uit die domeintijd een werkingstijd in de toekomst krijgen: 'P woont op A vanaf 1 december'. Hetzelfde geldt voor een besluit dat op een latere datum in werking treedt, of dat een vastgestelde looptijd heeft: dan ligt niet het begin, maar het einde van de werkingstijd in de toekomst. Een vraag naar de stand op 1 december krijgt dan nu al een antwoord.

Dat antwoord kan nog veranderen. Gaat de verhuizing niet door of verschuift de datum, dan volgt een nieuw gebeuren, zoals een intrekking of een gewijzigde aangifte, en daaruit een nieuwe afgeleide bewering met een latere systeemtijd. Dat is geen correctie: de eerdere aangifte was juist vastgelegd. Dezelfde vraag op dezelfde systeemtijd levert wel steeds hetzelfde antwoord (zie de herhaalbare vraag).

Hoe vast een toekomstige toestand staat, verschilt: een besluit legt die juridisch vast, een voornemen niet. Omdat het onderliggende gebeuren in het journaal staat, blijft herleidbaar waarop de toestand rust. Hoe zeker die is, behandelt het hoofdstuk Zekerheid.

Verstrekking

Een antwoord dat meerdere onderdelen combineert, bijvoorbeeld via een expand-mechanisme, toont al die onderdelen op dezelfde systeemtijd. Anders kan een afnemer een combinatie zien die nooit zo in het register heeft gestaan. Dit is het mechanisme achter de herhaalbare vraag: dezelfde vraag op dezelfde systeemtijd levert hetzelfde antwoord.

Een tijdparameter in een vraag heeft betrekking op de werkingstijd van de geleverde bewering als geheel. Omvat een verstrekking meerdere beweringen, elk met een eigen werkingstijd, dan worden bij elk daarvan eigen tijdparameters geleverd.

Een verstrekking hoeft de systeemtijd van de geleverde beweringen niet te bevatten. Meeleveren is soms ongewenst, omdat een afnemer er bijvoorbeeld een correctie uit kan afleiden. Om de vraag toch herhaalbaar te maken, kan het register een token meegeven dat naar de systeemtijd verwijst.

Verwerkingstijd

Tussen het vastleggen van een primaire bewering en het voortbrengen van een afgeleide bewering zit verwerkingstijd, en daarna duurt het nog even voordat een afnemer de gegevens ziet. Een afnemer kijkt daardoor altijd in potentie naar informatie die net niet meer actueel is. Dat is geen fout, maar een eigenschap van de architectuur; zie eventual consistency als ontwerpoverweging en de inherente beperkingen aan de herhaalbare vraag.

De systeemtijd zelf kan hier ook een rol in spelen. Een register kan als systeemtijd bijvoorbeeld het begin van het vastleggen kiezen, omdat het einde daarvan nog niet bekend is. Stel dat een bewering daardoor als systeemtijd 10:00 uur krijgt, maar pas om 10:05 uur beschikbaar is. Een afnemer die om 10:03 uur vraagt naar de stand van 10:02 uur, ziet die bewering niet. Stelt die afnemer om 10:06 uur dezelfde vraag, dan ziet die de bewering wel, want de systeemtijd ligt vóór 10:02 uur. Dezelfde vraag over hetzelfde moment levert dan een ander antwoord op, en daarmee is de herhaalbare vraag niet meer gegarandeerd.

Een vraag naar de stand op een bepaald moment is daarom pas betrouwbaar als er geen bewering met een eerdere systeemtijd meer onderweg kan zijn. Een register kan dat bereiken door zulke vragen te beperken tot een moment dat ver genoeg in het verleden ligt, of door beweringen na elkaar vast te leggen, zodat de volgorde van de systeemtijden gelijk is aan de volgorde van beschikbaar komen.

Bitemporaliteit

Wie werkingstijd en systeemtijd samen bijhoudt, werkt bitemporeel. Dat kan generiek, omdat beide in elk domein dezelfde betekenis hebben. Domeintijd is geen dimensie, maar inhoud.

Bitemporaliteit houdt twee vragen uit elkaar: wat gold er volgens het register op een bepaald moment, en wat onderschreef het register op een bepaald moment? De capability Historisch inzicht vraagt beide, en de herhaalbare vraag kan niet zonder zodra correcties met terugwerkende kracht mogelijk zijn.

Zet je de twee tegen elkaar af, dan ontstaat het bekende bitemporele blokkendiagram. Op de ene as staat de werkingstijd, op de andere de tijdlijn van het systeem, waarop een bewering loopt van voortbrenging tot onttrekking. Een toestandsbewering wordt daarin een blok: elk punt in dat vlak betekent dat de toestand gold, en dat het register dat op dat moment onderschreef. Voor gebeurenbeweringen werkt dat beeld niet. Een gebeurtenis heeft op de werkingstijdas geen breedte, en een blok voor een traject wekt de indruk dat het traject op elk moment binnen de periode waar is. Ook een gebeurenbewering beslaat wel een periode op de tijdlijn van het systeem, maar het blokkendiagram blijft een toestandslezing.

Het 'bi' geldt per bewering. Een juridisch of feitelijk perspectief is geen extra tijdas, maar een andere bewering. Ook een register met journaal en projecties, of een keten van registers, voegt geen dimensies toe, wel beweringen met elk een eigen systeemtijd.

Bitemporaliteit brengt complexiteit mee die niet altijd nodig is. Welke temporaliteit een projectie nodig heeft, is een ontwerpafweging.

Afspraken over API's

Uit de drie lagen volgt wat te standaardiseren is. Systeemtijd en werkingstijd hebben in elk domein dezelfde betekenis; daarover zijn generieke afspraken te maken, bijvoorbeeld over hoe een afnemer een peilmoment opgeeft, wat de standaard is als dat ontbreekt en hoe een antwoord herhaalbaar wordt. Domeintijdsgegevens zoals inwerkingtreding, inwinning of ontvangst verschillen per domein en horen in informatiemodellen. Die lijst kan groeien zonder dat een API-standaard meegroeit.

In API-afspraken is soms sprake van beschikbaarheidstijd, bijvoorbeeld in de temporal-extensie van het Kennisplatform API's van Geonovum: het moment waarop de geleverde gegevens via dezelfde API beschikbaar zijn. Vanuit deze handreiking bezien is dat een moment op de systeemtijdlijn van het systeem dat het antwoord levert. Andersom is niet elke systeemtijd een beschikbaarheidstijd: de systeemtijd van een primaire bewering ligt bijvoorbeeld vóór het moment waarop een afgeleide bewering via een API beschikbaar komt (zie Verwerkingstijd).

Verdieping

• De casus Keizersgracht 42 laat de tijdstippen uit dit hoofdstuk zien in gevolgen, projecties en notificaties.
• Tijdstippen en geldigheid werkt de tijdstippen van gevolgen en projecties uit.
• Temporaliteit in projecties gaat van actuele stand via unitemporaliteit naar bitemporaliteit.
• Tijd in andere kaders zet de namen voor tijd uit standaarden, modellen en literatuur naast de drie lagen.
• Bitemporele relationele databases beschrijft een tabelvorm voor bitemporele projecties.