NEN3610 Temporele Aspecten volledig consistent doorvoeren in IMBOR

O.a. ingegeven door: #1051 #1052 #1059 #634

Aanleiding

Doordat de link tussen IMBOR en de (nieuwe) NEN3610:2022 zo sterk is willen we deze consistenter doorvoeren. De redenen hiervoor zijn:

Geen eigen zaken meer bedenken, maar verwijzen naar de NEN3610 voor temporele aspecten (net zoals we dat voor 'Identificatie' doen);
Duidelijkheid voor de implementatie;
Consistentie in gebruik van attributen om temporele aspecten vast te leggen.

InformatieObject

De NEN3610, de NEN2660-2 en IMBOR maken op iets verschillende wijze gebruik van InformatieObject. Zie ook de TechDoc sectie hierover. Binnen de NE3610 is het InformatieObject ook de representatie van het Object in het systeem. Binnen IMBOR wordt het ook gebruikt als de plek voor het ophangen van attributen over het object (i.t.t. attributen van het object). De beslissing wordt hier dan ook genomen om attributen betreffende temporele aspecten, te weten:

beginGeldigheid
eindGeldigheid
tijdstipRegistrate
eindRegistratie
objectBegintijd
objectEindtijd

vast te (blijven) leggen op een InformatieObject (i.p.v. direct op het ObjectType). Bij objectBegintijd en objectEindtijd moet er vanuit de NEN3610 een keuze gemaakt worden voor een datatype. Deze stellen we bij IMBOR op xsd:date.

Splitsing NEN3610 en BOR registratie informatie

Omdat er vanuit de BOR sector een aantal aanvullende gegevens gevraagd worden (bijvoorbeeld de Wijziger) zullen we twee InformatieObjecten introduceren:

de klasse BOR-Registratie-informatie
de klasse NEN3610-Registratie-informatie

Waarbij de bovenstaande attributen dus de enige attributen zullen zijn op de klasse NEN3610-Registratie-informatie. De attributen op de klasse `BOR-Registratie-informatie zullen nader bekeken worden maar zullen waarschijnlijk in de trend zijn van:

aangemaaktDoor
gewijzigdDoor

De twee nieuwe klassen komen te hangen met de relatie isBeschrevenDoor en een multipliciteit van 0-1 aan de klasse GeoObject omdat dit in lijn is met de NEN3610. Aanvullend worden ze op dezelfde wijze gehangen aan InformatieObject en Activiteit. Hierdoor kan overal (behalve de Geometrie zelf) informatie over worden bijgehouden.

De klasse Registratie-informatie komt hiermee te vervallen (of wordt aangepast). En de klassen Inwinnings-informatie wordt ook nader bekeken.

Herziening van attributen

Er zijn een aantal bestaande attributen die binnen deze verandering opnieuw bekeken moeten worden. Per bestaand attribuut in scope moet bekeken worden:

waarom dit attribuut er in deze hoedanigheid is (en is in gekomen),
of het attribuut kan vervallen,
of het attribuut afgeleid kan worden van andere attributen,
de definitie van het attribuut herzien moet worden voor bestaansrecht.

Het betreffen tot nu toe de volgende attributen (er kunnen er meer geïdentificeerd worden):

mutatiedatum (kan eigenlijk verwijderd worden omdat dit afgeleid kan worden van tijdstipRegistratie)
levensduur (hangt samen met objectBegintijd en objectEindtijd, dus kan wellicht vervallen)
technische levensduur (is eigenlijk iets waarvan de expert zegt hoe lang het meegaat)
theoretisch eindjaar (zou dan wellicht ook objectEindtijd kunnen zijn)
inwinningsdatum
verwijderdatum

Impact

Omdat deze wijziging redelijk wat impact heeft zullen we deze ook ter review leggen bij gebruikers en leveranciers, voordat deze definitief wordt.

Addendum herziening attributen Voor alle attributen uit IMBOR 2022 waarop deze wijziging impact heeft, d.w.z. er sprake is van een semantische samenhang met een of meerdere attributen uit de attributenverzameling ten behoeve van temporele aspecten uit NEN3610, zijn in wat volgt de punten (1) t/m (4) uit het bovenstaande bericht uitgewerkt. Het gaat zowel om attributen die onderdeel uitmaken van bestaande InformatieObjecten (Registratie-informatie, Inwinning-informatie, Onderhoud-informatie, Oplever-informatie) als om reguliere attributen die toebehoren aan een Klasse voor ObjectTypen. De attributen zijn gesorteerd op alfabetische volgorde.

Methode Allereerst echter een toelichting voor hoe de oordelen met betrekking tot punten (1) t/m (4) tot stand zijn gekomen. Voor punt (1) 'de reden tot opname in IMBOR' is beredeneerd wat het nut is van de registratie van het gegeven en waartoe het de IMBOR-gebruiker in staat stelt. Het oordeel bij punt (2) 'mogelijkheid tot vervallen' is gestoeld op een beoordeling van de redundantie van de opname van het gegeven in aanvulling op de TijdlijnRegistratie dan wel de TijdlijnGeldigheid uit NEN3610:2022. De invulling van punt (3) 'afleidbaarheid' hangt hier nauw mee samen, maar dat het gegeven afleidbaar is uit een ander gegeven is op zichzelf nog geen voldoende reden tot het laten vervallen van dat gegeven. Mits er bij punt (2) niet is beargumenteerd dat het gegeven moet komen te vervallen, dan wordt er bij punt (4) 'voorgestelde herziening' een definitiewijziging voorgesteld die het gegeven ofwel compatibel maakt met de NEN3610, ofwel het tot een waardevolle aanvulling maakt op de NEN3610, ofwel het beter van de tijdlijnen uit de NEN3610 te onderscheidt.

N.B. Bij het beoordelen van alle voorstellen tot het laten vervallen van een attribuut is het echter belangrijk om de volgende passage uit NEN3610 in het achterhoofd te houden: "Sectormodellen kunnen daarnaast ook direct aan het object gekoppelde ontstaans- en verdwijningskenmerken zoals constructiedatum, datum oplevering, datum sloop, geboortedatum, enz. opnemen." (p. 54) Dit betekent dat de NEN3610 niet vijandig tegenover dergelijke aanvulling op de tijdlijnen staat.

Datum bob datum bob (maakt onderdeel uit van Holle leiding)

Reden tot opname in IMBOR: Dit attribuut is in IMBOR opgenomen om de "Datum waarop de actuele BOB-waarden geregistreerd zijn." vast te leggen. De ingevulde waarde geldt hier paradoxaal genoeg zowel voor bob begin als voor bob eind.
Mogelijkheid tot vervallen (incl. motivatie): Dit attribuut kan vervallen vanwege de redundantie met Inwinning-informatie. De volgende invulling van Inwinning-informatie is namelijk equivalent aan het gebruikt van datum bob en is gestandaardiseerd voor alle attributen en objecttypes i.t.t. tot datum bob: [Objecttype :: subKlasseVan :: Holle leiding] :: (1) isBeschrevenDoor :: Inwinning-informatie :: [inwinningsdatum :: [xsd:date]] :: [attribuut :: bob begin]; (2) isBeschrevenDoor :: Inwinning-informatie :: [inwinningsdatum :: [xsd:date]] :: [attribuut :: bob eind]. Daarbij komt dat de expressiecapaciteit van Inwinning-informatie groter is dan van die datum bob nu het verschil in inwinningsdatum voor bob begin en bob eind uitgedrukt kan worden. Het gebruik van datum bob faciliteert twee manieren om hetzelfde te registreren, wat onwenselijk is. Het vervallen heeft geen impact op de relatie tussen IMBOR en GWSW, omdat binnen GWSW aan de kenmerken B.o.b. beginpunt leiding en B.o.b. eindpunt leiding het kenmerk Inwinning is gekoppeld, met als beschrijvend gegeven 'Datum inwinning'. Dit is de GWSW-tegenhanger van Inwinning-informatie.
Afleidbaarheid: Het attribuut is afleidbaar uit Inwinning-informatie zoals bij punt (2) is aangetoond. Voor de afleidbaarheid van inwinningsdatum uit TijdstipRegistratie, zie de bespreking van dat attribuut hieronder.
Voorgestelde herziening (incl. motivatie): N.v.t. vanwege argumentatie voor vervallen onder punt (2).

Datum memo datum memo (maakt onderdeel uit van Memo)

Reden tot opname in IMBOR: Dit attribuut is in IMBOR opgenomen om de datum waarop een memoveld in de applicatie is ingevuld/aangemaakt te registreren. De noodzaak achter de opname van dit attribuut is het feit dat de facto het vaak onbekend is wanneer een memo is geregistreerd, wat de beheerbaarheid van memo's beperkte.
Mogelijkheid tot vervallen (incl. motivatie): Of er sprake is van redundantie tussen datum memo en TijdlijnRegistratie is een dubbelzinnige kwestie. Er is geen sprake van redundantie tussen datum memo en inwinningsdatum omdat een Memo geen gegeven is van een ObjectType, maar een opmerking over een ObjectType. Als zodanig is het niet zinnig om te spreken over de 'inwinning' van een Memo. Echter kan het tijdstip waarop een versie van een Memo tot stand komt binnen de applicatie wel uitgedrukt worden met tijdstipRegistratie en de tijdstip van diens einde met eindRegistratie uit TijdlijnRegistratie. Maar er is sprake van een verschil: bij het wijzigen van de inhoud van memoveld komt er een nieuwe versie van dezelfde Memo tot stand (Memo :: t=1), maar deze Memo moet dezelfde waarde voor datum memo behouden als de oorspronkelijke versie (Memo :: t=0), omdat in die constante het nut van het gebruik van datum memo is verankerd.
Afleidbaarheid: datum memo is afleidbaar uit de invulling van de tijdstipRegistratie uit de oorspronkelijke versie van Memo in de TijdlijnRegistratie.
Voorgestelde herziening (incl. motivatie): Om verwarring te voorkomen wordt er voorgesteld om de relatie met TijdlijnRegistratie op te nemen in de definitie: "Datum waarop de memo aan het object toegevoegd is. Deze datum kan afgeleid worden uit de tijdstipRegistratie, maar blijft persistent door wijzigingen van de TijdlijnRegistratie uit NEN3610 heen."

Inwinningsdatum inwinningsdatum (maakt onderdeel uit van Inwinning-informatie)

Reden tot opname in IMBOR: Dit attribuut is in IMBOR opgenomen om de datum waarop een domeinwaarde van een attribuut is ingewonnen te registreren.
Mogelijkheid tot vervallen (incl. motivatie): Het attribuut wordt niet genomineerd voor verval. Alhoewel de datum waarop een nieuwe versie van een domeinwaarde van een attribuut actueel wordt in de applicatie overeen kan komen met de TijdstipRegistratie van een ObjectType, namelijk als er in 'realtime' wordt ingewonnen, hoeft dit noodzakelijkerwijs niet zo te zijn, bijvoorbeeld als de dag van inwinning op een andere datum valt dan de dag van registratie in de applicatie. Daarnaast is er geen sprake van redundantie met beginGeldigheid omdat het inwinnen van een toestand van het object van een ObjectType in de werkelijkheid, niet hetzelfde is als de totstandkoming van een nieuwe toestand van het object van een ObjectType in de werkelijkheid. Tot slot is het niet wenselijk als inwinningsdatum meewijzigt met TijdstipRegistratie.
Afleidbaarheid: Het gegeven is niet logisch afleidbaar uit een ander IMBOR- of NEN3610-temporeel gegeven.
Voorgestelde herziening (incl. motivatie): Om verwarring te voorkomen is het voorstel om de definitie te wijzigen naar: "Datum waarop het gegeven in werkelijkheid ingewonnen is."

Jaar herinrichting jaar herinrichting (maakt onderdeel uit van Hondenbeleidsgebied en Speelterrein)

Reden tot opname in IMBOR: Het attribuut is in IMBOR opgenomen om onderscheid te kunnen maken tussen het jaar van aanleg van een ObjectType van de klasse Begroeiing of Verharding waar een Hondenbeleidsgebied en Speelterrein uit bestaat. De aanleg van de ondergrond hoeft namelijk niet overeen te komen met de herinrichting van een Hondenbeleidsgebied of een Speelterrein.
Mogelijkheid tot vervallen (incl. motivatie):
Afleidbaarheid: Het jaartal van jaar herinrichting is afleidbaar uit de datum van beginGeldigheid van de TijdlijnGeldigheid, waarbij het begin van de geldigheid van een nieuwe versie van het object in de werkelijkheid wordt beschouwd als de herinrichting. Dit heeft geen raakvlakken met objectBeginTijd omdat dat gegeven betrekking heeft op de ObjectTypen die binnen het gebied vallen.
Voorgestelde herziening (incl. motivatie): Om verwarring te voorkomen wordt er voorgesteld om de relatie met TijdlijnGeldigheid op te nemen in de definitie: "Jaar waarin het gebied heringericht is. Dit jaartal kan afgeleid worden uit de beginGeldigheid, waarbij het overeenkomt met het begin van de versie die tot stand is gekomen door een herinrichting uit de TijdlijnGeldigheid van NEN3610."

Jaar van aanleg jaar van aanleg (maakt onderdeel uit van Reëel object)

Reden tot opname in IMBOR: Het attribuut is in IMBOR opgenomen om het jaar waarin de aanleg van een object heeft plaatsgevonden te registreren voor beheerdoeleinden.
Mogelijkheid tot vervallen (incl. motivatie): Ook al is dit gegeven afleidbaar, is er geen reden om dit gegeven te laten vervallen, omdat de afleiding duidelijke praktische relevantie heeft, net als het gebruik van plaatsingsdatum. Daarnaast is het een gegeven dat, ook al correspondeert het met de eerste instantie van beginGeldigheid, vervolgens niet meer aan verandering onderhevig is.
Afleidbaarheid: Het jaartal van jaar van aanleg is afleidbaar uit de datum van de oorspronkelijke waarde va beginGeldigheid van de TijdlijnGeldigheid (eerste versie van het object in de tijdlijn). Dit raakt aan de objectBeginTijd omdat de levensduur van het ObjectTypen begint in het jaar van aanleg. Maar omdat objectBeginTijd zelf een afgeleide is van beginGeldigheid, kan jaar van aanleg niet worden beschouwd als afgeleide van objectBeginTijd. beginGeldigheid is als synoniem opgenomen in IMBOR 2022, maar dat is strikt genomen onjuist omdat NEN3610 niet toestaat dat beginGeldigheid xsd:gYear is.
Voorgestelde herziening (incl. motivatie):
- Verwijder synoniem beginGeldigheid;
- Om verwarring te voorkomen wordt er voorgesteld om de relatie met TijdlijnGeldigheid op te nemen in de definitie: "Jaar waarin het beheerobject is aangelegd of aangeplant (kan ook voor de plaatsingsdatum gebruikt worden). Dit jaartal kan afgeleid worden uit de beginGeldigheid, waarbij het overeenkomt met het begin van de eerste versie van het object uit de TijdlijnGeldigheid van NEN3610."

Leeftijd leeftijd (maakt onderdeel uit van Boom)

Reden tot opname in IMBOR: Voor bomen is het van belang te weten hoe oud ze zijn of dit te schatten.
Mogelijkheid tot vervallen (incl. motivatie): Dit gegeven kan niet vervallen, omdat kiemjaar vaak onbekend is. leeftijd wordt vervolgens een zelfstandig geschat gegeven op basis van boomkenmerken, i.t.t. tot een volledig afgeleid gegeven.
Afleidbaarheid: leeftijd is voor een Boom een afgeleid gegeven van kiemjaar. Stel dat dit attribuut toegeschreven wordt aan een andere Klasse, dan zou het een afgeleid gegeven zijn van jaar van aanleg, oftewel van de eerste instantie van beginGeldigheid.
Voorgestelde herziening (incl. motivatie): Tenzij er niet geopteerd wordt voor het laten vervallen van dit attribuut, is deze suggestie niet van toepassing: wanneer leeftijd bij andere Klassen wordt opgenomen, moet de relatie met de eerste instantie van beginGeldigheid volgen uit de definitie van leeftijd, wat nu niet het geval is.

Levensduur levensduur (maakt onderdeel uit van Onderhoud-informatie)

Reden tot opname in IMBOR: Het attribuut is in IMBOR opgenomen om de verwachte levensduur (kan het resultaat zijn van een berekening) te registreren voor beheerdoeleinden (bijv. 'wanneer is dit object aan de beurt voor onderhoud, gebaseerd op haar levensduur?').
Mogelijkheid tot vervallen (incl. motivatie): Dit gegeven moet voor conformiteit met NEN3610 komen te vervallen binnen Onderhoud-informatie en worden opgenomen binnen NEN3610-Registratie-informatie omdat de NEN3610 voorschrijft om levensduur te baseren op objectBeginTijd en objectEindTijd.
Afleidbaarheid: Op dit moment is het gegeven niet afleidbaar (kan het resultaat zijn van een berekening die verschilt per object). Volgens de NEN3610 wordt levensduur echter afgeleid uit objectBeginTijd en objectEindTijd.
Voorgestelde herziening (incl. motivatie):
- Opname van levensduur bij NEN3610-Registratie-informatie met als definitie: "Typering dat dit attribuut wordt gebruikt voor de vastlegging van het tijdsinterval waarin dit informatieobject de werkelijkheid representeert."
- Voor het handhaven van levensduur in de huidige betekenis binnen IMBOR als geschat gegeven voor beheerdoeleinden, zijn de volgende wijzigingen nodig: 1) wijziging van de naam levensduur naar berekende levensduur; 2) wijziging van de definitie naar: "Op basis van werkelijke kenmerken berekende levensduur van het beheerobject."

Mutatiedatum mutatiedatum (maakt onderdeel uit van Registratie-informatie)

Reden tot opname in IMBOR: Dit attribuut maakt onderdeel uit van Registratie-informatie samen met gewijzigd door om historie te kunnen opbouwen van wie wat wanneer heeft gewijzigd.
Mogelijkheid tot vervallen (incl. motivatie): Het is niet wenselijk om dit
Afleidbaarheid: mutatiedatum is afleidbaar uit de tijdstipRegistratie van de meest actuele versie van het object in de TijdlijnRegistratie.
Voorgestelde herziening (incl. motivatie): Om verwarring te voorkomen wordt er voorgesteld om de relatie met TijdlijnRegistratie op te nemen in de definitie: "Datum waarop de digitale gegevens van het beheerobject voor het laatst gewijzigd zijn. Deze datum kan afgeleid worden uit de tijdstipRegistratie, waarbij het overeenkomt met het begin van de actuele versie van het object uit de TijdlijnRegistratie van NEN3610.""

Plaatsingsdatum plaatsingsdatum (maakt onderdeel uit van Oplever-informatie)

Reden tot opname in IMBOR: Het attribuut is in IMBOR opgenomen om de datum waarin het object is geplaatst in de openbare ruimte te registreren voor beheerdoeleinden.
Mogelijkheid tot vervallen (incl. motivatie): Dit attribuut kan vervallen omdat het een letterlijke afgeleide is van beginGeldigheid, maar aan beginGeldigheid hangt niet de functie van plaatsingsdatum. Dit kan voor de gebruiker voor verwarring zorgen. Echter is het zo dat onder N.B. is uitgelegd dat NEN3610 niet vijandig tegenover toepassingen als deze staat.
Afleidbaarheid: De datum van plaatsingsdatum is afleidbaar uit de datum van de oorspronkelijke waarde va beginGeldigheid van de TijdlijnGeldigheid (eerste versie van het object in de tijdlijn).
Voorgestelde herziening (incl. motivatie): Om verwarring te voorkomen wordt er voorgesteld om de relatie met TijdlijnGeldigheid op te nemen in de definitie: "Datum waarop op het object geplaatst is (exacte datum als bewijslast). Deze datum kan afgeleid worden uit de beginGeldigheid, waarbij het overeenkomt met het begin van de eerste versie van het object uit de TijdlijnGeldigheid van NEN3610."

Praktisch eindjaar praktisch eindjaar (maakt onderdeel uit van Constructieonderdeel)

Reden tot opname in IMBOR: Op dit moment is dit attribuut alleen van toepassing bij de klasse Constructieonderdeel om het jaar waarin het onderdeel op haar einde is te registreren.
Mogelijkheid tot vervallen (incl. motivatie): Ook al is dit gegeven afleidbaar, is er geen directe reden om dit gegeven te laten vervallen, omdat de afleiding duidelijke praktische relevantie heeft. praktisch eindjaar leidt namelijk tot een inspectie voor een mogelijke vervangingsmaatregel, terwijl objectEindTijd de feitelijke of geschatte datum waarop het ObjectType vervalt is. Daarnaast is het zo dat onder N.B. is uitgelegd dat NEN3610 niet vijandig tegenover toepassingen als deze staat.
Afleidbaarheid: Op basis van de definitie kan bepaald worden ("Jaar dat een object in de praktijk aan het einde van haar levensduur is.") dat dit gegeven een afgeleide is van objectEindTijd.
Voorgestelde herziening (incl. motivatie): Om verwarring te voorkomen wordt er voorgesteld om de relatie met TijdlijnGeldigheid op te nemen in de definitie: "Jaar dat een object in de praktijk aan het einde van haar levensduur is. Dit jaartal kan afgeleid worden uit de objectEindTijd waarbij het overeenkomt met het geschatte einde van de volledige TijdlijnGeldigheid van NEN3610."

Registratiedatum registratiedatum (maakt onderdeel uit van Soortnaam groenobject)

Reden tot opname in IMBOR: Op dit moment is dit attribuut alleen van toepassing bij de klasse Soortnaam groenobject voor het registreren van de datum van toevoeging van een soortnaam bij een ObjectType.
Mogelijkheid tot vervallen (incl. motivatie): Dit gegeven kan niet komen te vervallen omdat het niet redundant is bij het gebruik van NEN3610-Registratie-informatie.
Afleidbaarheid: registratiedatum is afleidbaar van de eerste instantie van tijdstipRegistratie voor Soortnaam groenobject, maar is per definitie niet gelijk aan de opeenvolgende instanties van tijdstipRegistratie die toebehoren aan latere versies van Soortnaam groenobject in TijdlijnRegistratie.
Voorgestelde herziening (incl. motivatie): Om verwarring te voorkomen worden er twee wijzigingen voorgesteld:
- Naamswijziging van registratiedatum naar registratiedatum soortnaam om duidelijk te maken dat dit attribuut niet tot BOR-Registratie-informatie of NEN3610-Registratie-informatie behoort.
- Wijziging van de definitie om zowel de naamswijziging als de relatie met TijdlijnRegistratie te accomoderen:

Technische levensduur technische levensduur (maakt onderdeel uit van Onderhoud-informatie)

Reden tot opname in IMBOR: De technische levensduur is een gegeven dat afkomstig is uit NEN2767 en tot stand komt op basis van die norm en daarbinnen een functie vervult.
Mogelijkheid tot vervallen (incl. motivatie): technische levensduur is een gegeven uit een andere NEN-norm en mag als zodanig niet vervallen.
Afleidbaarheid: Het attribuut is niet afleidbaar uit NEN3610-Registratie-informatie.
Voorgestelde herziening (incl. motivatie): Om verwarring te voorkomen met levensduur en berekende levensduur wordt er voorgesteld om de relatie met NEN2767 op te nemen in de definitie: "De periode waarin wordt verondersteld dat een bouwdeel een bepaald technisch niveau kan behouden. Dit gegeven maakt onderdeel uit van NEN2767-4."

Theoretisch eindjaar theoretisch eindjaar (maakt onderdeel uit van Reëel object)

Reden tot opname in IMBOR: Het attribuut is in IMBOR opgenomen om een toekomstig jaartal aan te wijzen waarin de levensduur van het object in theorie eindigt. In de praktijk hoeft dit niet zo te geschieden.
Mogelijkheid tot vervallen (incl. motivatie): Er wordt voorgesteld te opteren om dit gegeven niet te laten vervallen omdat het slechts onder specifieke omstandigheden afleidbaar is uit NEN3610-Registratie-informatie, wat het pragmatischer maakt om het als zelfstandig gegeven op te nemen waarbij de totstandkoming van het gegeven in het midden wordt gelaten.
Afleidbaarheid: Dit gegeven kan worden afgeleid uit objectEindTijd dan en slechts dan als de objectEindTijd van objecten ook wordt ingevuld op basis van een schatting, berekening of overname van de berekende levensduur en objectBeginTijd zodat aan de definitie van theoretisch eindjaar ("Jaar dat het beheerobject aan het theoretische einde van haar levensduur is.") recht wordt gedaan. Dit is vergezocht, omdat objectEindTijd dient om levensduur uit af te leiden, maar niet om tot stand te komen op basis van een BOR-gegeven zoals berekende levensduur. Daarnaast is het zo dat onder N.B. is uitgelegd dat NEN3610 niet vijandig tegenover toepassingen als deze staat.
Voorgestelde herziening (incl. motivatie): Er zijn geen wijzigingen benodigd.

Vernieuwingsdatum vernieuwingsdatum (maakt onderdeel uit van Bord)

Reden tot opname in IMBOR: Op dit moment is dit attribuut alleen van toepassing bij de klasse Bord.
Mogelijkheid tot vervallen (incl. motivatie): Dit attribuut kan vervallen op basis van de sterke mate van afleidbaarheid.
Afleidbaarheid: De definitie van vernieuwingsdatum ("Datum waarop op het object vernieuwd is.") maakt dat het overeenkomt met het begin van een nieuwe versie van de TijdlijnGeldigheid van het object. vernieuwingsdatum is dus afleidbaar uit elke nieuwe beginGeldigheid, niet zijnde de eerste instantie van beginGeldigheid. Toch moet er opgemerkt wordne dat het zo is dat onder N.B. is uitgelegd dat NEN3610 niet vijandig tegenover toepassingen als deze staat.
Voorgestelde herziening (incl. motivatie): Mocht er niet geopteerd worden om dit attribuut te laten vervallen, dan wordt om verwarring te voorkomen de volgende definitiewijziging voorgesteld: "Datum waarop op het object vernieuwd is. De datum van dit attribuut kan afgeleid worden uit elke nieuwe beginGeldigheid, niet zijnde de eerste instantie van beginGeldigheid, uit de TijdlijnGeldigheid van NEN3610."

Vervangingsjaar vervangingsjaar (maakt onderdeel uit van Onderhoud-informatie)

Reden tot opname in IMBOR: Het attribuut is in IMBOR opgenomen om een toekomstig jaartal aan te wijzen waarin de IMBOR-gebruiker het object moet vervangen. Het maakt geen onderdeel van de definitie uit ("Jaar dat het beheerobject vervangen moet worden.") hoe dit gegeven is gekomen.
Mogelijkheid tot vervallen (incl. motivatie): Dit attribuut kan niet komen te vervallen, omdat het niet op een redundante manier afleidbaar is uit een ander attribuut.
Afleidbaarheid: Dit attribuut is niet afleidbaar uit NEN3610-Registratie-informatie omdat er geen noodzakelijke causaliteit bestaat tussen de vervanging van een objecttype (als gevolg) en de eindeGeldigheid (als oorzaak). Een eindeGeldigheid impliceert geen vervanging. Een vervanging impliceert echter wel een eindeGeldigheid. Dit betekent dat eindeGeldigheid afleidbaar is uit vervangingsjaar, wanneer het vervangingsjaar heeft plaatsgehad en er ook daadwerkelijk vervanging heeft plaatsgevonden. Ook hier is er geen sprake van noodzakelijke causaliteit, maar slechts van een logische relatie onder bepaalde voorwaarden.
Voorgestelde herziening (incl. motivatie): Er zijn geen wijzigingen benodigd, vanwege de conclusie van punt (3).

Verwijderdatum verwijderdatum (maakt onderdeel uit van Registratie-informatie)

Reden tot opname in IMBOR: Het attribuut is in IMBOR opgenomen om een toekomstig jaartal aan te wijzen waarin een object niet langer bestaat in de werkelijkheid en is verwijderd uit de verzameling bestaande objecten in de applicatie (tot historie is geworden).
Mogelijkheid tot vervallen (incl. motivatie): Vanwege de equivalentie met eindeGeldigheid kan het attribuut komen te vervallen; eindeGeldigheid wordt immers toegoevoegd als onderdeel van NEN3610-Registratie-informatie.
Afleidbaarheid: verwijderdatum is per definitie ("Datum waarop de gegevens van een beheerobject verwijderd zijn, ook wel EindeGeldigheid genoemd.") een synoniem van eindeGeldigheid en is daarom volledig afleidbaar uit NEN3610-Registratie-informatie.
Voorgestelde herziening (incl. motivatie): N.v.t. vanwege argumentatie voor vervallen onder punt (2).

Korte conclusie:

Datum bob datum bob (maakt onderdeel uit van Holle leiding)

Dit attribuut vervalt dus omdat het met de NEN3610 attributen geregistreerd kan worden.

Korte conclusie:

Datum memo datum memo (maakt onderdeel uit van Memo)

Dit attribuut vervalt dus omdat het met de NEN3610 attributen geregistreerd kan worden.

Korte conclusie:

Inwinningsdatum inwinningsdatum (maakt onderdeel uit van Inwinning-informatie) Het gaat hier om de datum van de activiteit van het inwinnen. En dit kan ook met NEN3610 wederom consistent geregistreerd worden. Dit attribuut vervalt dus omdat het met de NEN3610 attributen geregistreerd kan worden.

Bij nader inzien gaan we de volgende aanpak hanteren:

@wjtmollema en @RiX012 gaan een afspraak plannen met Geonovum om te toetsen hoe de NEN3610 temporele aspecten goed in IMBOR verwerkt zouden moeten worden
We gaan generieke uitspraken doen hoe NEN3610 temporele aspecten toe te passen
We gaan bovenstaande attributen langs met de kennis uit de vorige twee punten om dit consistent in IMBOR door te voeren
We toetsen de werkwijze en impact bij de softwareleveranciers en voeren op basis daarvan de wijzigingen door

@wjtmollema en @RiX012 gaan een afspraak plannen met Geonovum om te toetsen hoe de NEN3610 temporele aspecten goed in IMBOR verwerkt zouden moeten worden

Afspraak is geweest. Conclusie is dat de NEN3610 redelijk wat flexibiliteit biedt (die we nodig hebben) en dat we al een eind op weg zijn.

Voorstel is als volgt:

Waarna we vervolgens in de definities van bepaalde attributen (hiervoor genoemd) gaan vermelden of het gewenst is deze af te leiden van de NEN3610 attributen.

Corollarium in het licht van de recente ontwikkelingen

In het onderstaande worden voor alle temporele attributen uit het huidige IMBOR 2022 de voorgestelde verwerking uit https://github.com/Stichting-CROW/imbor/issues/1075#issuecomment-1365909294 herzien in het licht van de vernieuwde modellering uit https://github.com/Stichting-CROW/imbor/issues/1075#issuecomment-1463637312.

Dit bericht is onderhevig aan werk in uitvoering.

Ter verheldering:

Bij Fysiek object is het voorstel dat de volgende IMBOR-subKlassen van <NEN 3610: metadata, Objecttype> Registratie geïmplementeerd worden: TijdlijnRegistratie, TijdlijnGeldigheid, Levensduur, Versie. Bij InformatieObject is het voorstel dat de volgende IMBOR-subKlassen van <NEN 3610: metadata, Objecttype> Registratie geïmplementeerd worden: TijdlijnRegistratie, Versie.

Dit is toegestaan vanwege de ingebouwde flexibiliteit van NEN 3610: 2022 par. 8.3.

Temporele attributen uit IMBOR

Datum bob De conclusie uit https://github.com/Stichting-CROW/imbor/issues/1075#issuecomment-1415925623 blijft gehandhaafd, omdat het met de IMBOR-expressies [Objecttype :: subKlasseVan :: Holle leiding] :: (1) isBeschrevenDoor :: Inwinning-informatie :: [inwinningsdatum :: [xsd:date]] :: [attribuut :: bob begin]; (2) isBeschrevenDoor :: Inwinning-informatie :: [inwinningsdatum :: [xsd:date]] :: [attribuut :: bob eind] ondervangen kan worden. Conclusie na bespreking binnen het IMBOR-team: conclusie geaccepteerd.
Datum memo De conclusie uit https://github.com/Stichting-CROW/imbor/issues/1075#issuecomment-1415935496 blijft gehandhaafd omdat dit met de implementatie van tijdstipRegistratie als onderdeel van TijdlijnRegistratie binnen Memo redundant is geworden. Het is namelijk gelijk aan korte datumnotatie van de waarde van tijdstipRegistratie bij versie = 1 van memo. Conclusie na bespreking binnen het IMBOR-team: conclusie geaccepteerd.
Inwinningsdatum De conclusie uit https://github.com/Stichting-CROW/imbor/issues/1075#issuecomment-1415976388 blijft niet gehandhaafd omdat er bij InformatieObject niet gekozen wordt voor het implementeren van TijdlijnGeldigheid. Hierdoor is er geen semantisch conflict tussen inwinningsdatum en beginGeldigheid van Inwinning-informatie of het ObjectType dat wordt beschrevenDoor Inwinning-informatie. Conclusie na bespreking binnen het IMBOR-team: conclusie geaccepteerd.
Jaar herinrichting De initiële conclusie dat jaar herinrichting afgeleid kan worden uit beginGeldigheid van versie = 1 van TijdlijnGeldigheid is is mogelijk, maar gaat echter niet altijd op (bijvoorbeeld als de gegevens van een Speelterrein in een applicatie al geldig zijn in 2023, terwijl de herinrichting pas plaatsvindt in 2024 en dit al bekend is. Er wordt daarom voorgesteld dit attribuut in de huidige vorm te handhaven. Conclusie na bespreking binnen het IMBOR-team: conclusie geaccepteerd.
Jaar van aanleg
1. Verwijder synoniem beginGeldigheid;
2. Er wordt niet voorgesteld om een verwijzing naar de TijdlijnGeldigheid of Levensduur op te nemen in de definitie, omdat het ten eerste zo kan zijn dat versie = 1 met een beginGeldigheid een geldige representatie is van de werkelijkheid voordat een object is aangelegd en ten tweede omdat het niet strikt afleidbaar is uit objectBeginTijd, omdat een object kan bestaan voordat het is aangelegd. Conclusie na bespreking binnen het IMBOR-team: conclusie geaccepteerd.
Leeftijd De conclusie uit het vorige bericht blijft gehandhaafd, met de aanpassing dat leeftijd niet uit beginGeldigheid, maar uit objectBeginTijd moet worden afgeleid en dat dit in de definitie van leeftijd kan worden opgenomen. Conclusie na bespreking binnen het IMBOR-team: Laten vervallen; dit is heroverweging in het licht van de afstemming met het Handboek Bomen 2022 en het doorvoeren van een stringentere scheiding tussen IMBOR-gegevens en dynamische gegevens.
Levensduur Binnen IMBOR wordt er onderscheid gemaakt tussen levensduur en technische levensduur. technische levensduur is een verwachte levensduur, waarvoor de voorgestelde definitie is: "De periode waarin wordt verondersteld dat een bouwdeel een bepaald technisch niveau kan behouden. Dit gegeven maakt onderdeel uit van NEN2767-4." Anderzijds zal levensduur op twee semantisch conflicterende manieren worden gebruikt: enerzijds als subKlasseVan Registratie en als tijdsspanne tussen objectBeginTijd en objectEindTijd, anderzijds als niet-NEN2767-4 gegeven over de verwachte levensduur van een object op basis waarvan beheeracties zoals vervangingen en onderhoud gestuurd kunnen worden. Het voorstel is hier dan ook om de naam van levensduur aan te passen naar verwachte levensduur met als definitie: "Op basis van werkelijke kenmerken berekende levensduur van het beheerobject." De vorige conclusie dat levensduur opgenomen moet worden binnen Registratie-informatie is inmiddels achterhaald door de implementatie van Levensduur als subKlasseVan Registratie. Conclusie na bespreking binnen het IMBOR-team:levensduur is bij nader inzien een inspectiegegeven en daarom komt het te vervallen. technische levensduur blijft gehandhaafd onder een nieuwe definitie omdat het een gegeven is dat bij aanleg bekend is. Het hier bedoelde gegeven is niet hetzelfde als het NEN2767-4-gegeven. De volgende aangepaste definitie wordt voorgesteld: "De tijdsduur dat het object na fabricatie vanaf de ingebruikname haar technische functie adequaat kan vervullen.".
Mutatiedatum Vanwege de implementatie van tijdstipRegistratie als onderdeel van TijdlijnRegistratie binnen Fysiek object is mutatiedatum redundant geworden. Het komt te vervallen evenals de klasse Registratie-informatie zelf. Voor gewijzigd door en aangemaakt door zie de nieuwe klasse TijdlijnRegistratie zoals de bovenstaande afbeelding toont. mutatiedatum kan gemakkelijk afgeleid worden t.b.v. gebruikerspresentatie door een Date invoermasker over de DateTime van tijdstipRegistratie te leggen, mits gewenst. Conclusie na bespreking binnen het IMBOR-team: conclusie geaccepteerd.
Plaatsingsdatum Omdat TijdlijnGeldigheid niet wordt geïmplementeerd in Onderhoud-informatie is plaatsingsdatum niet redundant. Het is tevens logisch om een TijdlijnRegistratie van wijzigingen in plaatsingsdatum mogelijk te maken. Conclusie na bespreking binnen het IMBOR-team: conclusie geaccepteerd.
Praktisch eindjaar Voortbordurend op de conclusie die is getrokken onder levensduur, is het wijs om de definitie van praktisch eindjaar aan te passen. Voorgestelde wijziging: "Jaar dat een object in de praktijk aan het einde van haar levensduur is. Dit jaartal kan afgeleid worden uit de objectBeginTijd van de Levensduur van object in combinatie met de verwachte levensduur van een object." Conclusie a bespreking binnen het IMBOR-team: Bij nader inzien een resultaat van een inspectiegegeven en behoort aldus te vervallen.
Productiejaar productiejaar is een gegeven dat op dit moment bij Bord, Installatie, Paal en Sensor is opgenomen. Vaak kan dit gegeven afgelezen worden van documentatie op het object zelf. In de definitie van productiejaar kan een relatie met objectBeginTijd worden gespecificeerd, omdat het object in dat specifieke jaar is ontstaan. Voor beginGeldigheid kan dit niet het geval zijn, omdat het geproduceerd zijn nog niets zegt over vanaf wanneer een representatie van het object als informatieobject een geldige representatie van de werkelijkheid was. Conclusie na bespreking binnen het IMBOR-team: conclusie geaccepteerd.
Registratiedatum Dit attribuut kan komen te vervallen omdat het met de implementatie van tijdstipRegistratie als onderdeel van TijdlijnRegistratie binnen Soortnaam groenobject redundant is geworden. Het is namelijk gelijk aan aan korte datumnotatie van de waarde van tijdstipRegistratie bij versie = 1 van Soortnaam groenobject. Conclusie na bespreking binnen het IMBOR-team: conclusie geaccepteerd.
1006 : datum inschrijving monumentenregister

Dit attribuut wil het tijdsstip vastleggen dat een monument is opgenomen als monument van een bepaald type. Deze datum kan corresponderen met het besluit binnen de IMBOR-registratie dat een object benoemd is als monument, maar het kan ook verwijzen naar een datum, mogelijk zowel in de toekomst als in het verleden liggend, die door een externe instantie is benoemd en/of is ontleend aan een extern register, bijvoorbeeld een gemeentelijk monumentenregister of her Rijksmonumentenregister. Dit specifieke gebruik van een datumveld, correspondeert, zoals duidelijk mag zijn, niet met tijdstipRegistratie of beginGeldigheid of objectBeginTijd. Conclusie na bespreking binnen het IMBOR-team: conclusie geaccepteerd.
Technische levensduur Zie de conclusie die is getrokken omtrent levensduur hierboven.
Theoretisch eindjaar Voortbordurend op de conclusie die is getrokken onder levensduur, is het wijs om de definitie van theoretisch eindjaar aan te passen, ook om het beter te kunnen onderscheiden van praktisch eindjaar: "Jaar dat het beheerobject aan het theoretische einde van haar levensduur is. Dit jaartal kan afgeleid worden uit het jaar van aanleg van object in combinatie met de technische levensduur van een object." Conclusie: Redundant gegeven vanwege de berekende aard van het gegeven en behoort derhalve te vervallen.
Vernieuwingsdatum Het is onduidelijk waarom dit attribuut bij de klasse Bord is beland. In navolging van de conclusie uit het vorige bericht wordt voor het laten vervallen van dit attribuut geopteerd, omdat het sterk afleidbaar is uit een wijziging in de TijdlijnGeldigheid van een Bord. Anderzijds zijn ook plaatsingsdatum van Oplever-informatie en vervangingsjaar van Onderhoud-informatie beschikbaar. Conclusie na bespreking binnen het IMBOR-team: conclusie geaccepteerd.
Vervangingsjaar Conform de conclusie uit het vorige bericht wordt er beargumenteerd vervangingsjaar te handhaven, omdat het niet strikt afleidbaar is uit Levensduur of TijdlijnGeldigheid. Wanneer een object vervangen wordt, is namelijk niet te allen tijde logisch afleidbaar uit de geldigheid van een bepaalde representatie van een object, omdat vervanging ook te maken heeft met de werkcapaciteit van een organisatie en andere dynamische aspecten van vervangingsbeleid en -planning. Conclusie na bespreking binnen het IMBOR-team: Wijzigen naar 'gepland vervangingsjaar'
Verwijderdatum Vanwege de implementatie van eindRegistratie als onderdeel van TijdlijnRegistratie binnen Fysiek object is mutatiedatum redundant geworden. Het komt te vervallen evenals de klasse Registratie-informatie zelf. Voor gewijzigd door en aangemaakt door zie de nieuwe klasse TijdlijnRegistratie zoals de bovenstaande afbeelding toont. verwijdersatum kan gemakkelijk afgeleid worden t.b.v. gebruikerspresentatie door een Date invoermasker over de DateTime van tijdstipRegistratie te leggen, mits gewenst. Conclusie na bespreking binnen het IMBOR-team: conclusie geaccepteerd.

Verwerken zoals voorgesteld. Maar dit wordt nog besproken met de NEN3610. Daar kunnen wijzigingen uitkomen. Daarnaast is dit ook een dergelijk 'major' change dat dit aan de softwareleveranciers gepresenteerd moet worden.

Wordt verwerkt zoals voorgesteld in https://github.com/Stichting-CROW/imbor/issues/1075#issuecomment-1464027218 en https://github.com/Stichting-CROW/imbor/issues/1075#issuecomment-1463637312. De issue blijft openstaan in afwachting van de volgende zaken:

Validatie door vertegenwoordigers van NEN 3610;
Feedback van softwareleveranciers;

@wjtmollema en @RiX012 gaan een afspraak plannen met Geonovum om te toetsen hoe de NEN3610 temporele aspecten goed in IMBOR verwerkt zouden moeten worden

Afspraak is geweest. Conclusie is dat de NEN3610 redelijk wat flexibiliteit biedt (die we nodig hebben) en dat we al een eind op weg zijn.

Voorstel is als volgt:

Waarna we vervolgens in de definities van bepaalde attributen (hiervoor genoemd) gaan vermelden of het gewenst is deze af te leiden van de NEN3610 attributen.

@RiX012 In deze weergave van de implementatie van de Temporele aspecten dient nog gespecificeerd te worden of de relaties die lopen van TijdlijnRegistratie, TijdlijnGeldigheid, Levensduur en Versie naar Fysiek object en Informatieobject NEN 3610 : geregistreerdMet of IMBOR : implementeert zijn. Zijn ze NEN 3610 : geregistreerdMet, dan dient deze semantische relatie opgenomen te worden in IMBOR, maar moeten de pijlen nog steeds aangepast worden naar de grijze relatiepijl, wijzend van Fysiek object en Informatieobject naar TijdlijnRegistratie, TijdlijnGeldigheid, Levensduur en Versie met als inscriptie geregistreerdMet. Zijn ze echter IMBOR : implementeert, dan moeten de pijlen omgedraaid worden en aangepast worden naar de 'implementatiepijl' (witte kop) en hoeft de semantische relatie geregistreerdMet (voor zover ik kan overzien) niet opgenomen te worden.

Vanuit IMBOR vinden wij nen3610:geregistreerdMet eigenlijk een rdfs:subPropertyOf nen2660:isDescribedBy. Dit gaan we echter checken bij Geonovum en de NEN. Vanuit daar gaan we kijken of we isGeregistreerdMet ook daadwerkelijk in IMBOR gaan opnemen als relatie voor bovenstaande 4 klassen.

Vanuit IMBOR vinden wij nen3610:geregistreerdMet eigenlijk een rdfs:subPropertyOf nen2660:isDescribedBy. Dit gaan we echter checken bij Geonovum en de NEN. Vanuit daar gaan we kijken of we isGeregistreerdMet ook daadwerkelijk in IMBOR gaan opnemen als relatie voor bovenstaande 4 klassen.

Zojuist bij Michel (NEN2660) en Paul (NEN3610) geverifieerd. nen3610:geregistreerdMet > rdfs:subPropertyOf > nen2660:isDescribedBy is een correct statement wat we binnen IMBOR aan kunnen houden. Het is nog niet duidelijk of dit statement ook zijn weg zal vinden naar een of beide normen. We gaan dit uiteraard binnen IMBOR declareren. We hoeven dan niet persé geregistreerdMet op te nemen binnen IMBOR, maar wellicht dat dit wel meer duidelijkheid geeft. Misschien overleggen met softwareleveranciers?

Bespreken met de softwareleveranciers is sowieso een goed idee, als specifiek onderdeel van het bespreken van het doorvoeren van de NEN3610 temporele aspecten in het algemeen.

Het lijkt mij goed om nen3610:geregistreerdMet wel als afzonderlijke semantische relatie op te nemen, omdat op basis van de verkregen informatie gesteld kan worden dat alle instanties van nen3610:geregistreerdMet ook instanties van nen2660:isDescribedBy zijn, maar dat omgekeerde niet altijd waar is, oftewel:

Als nen3610:geregistreerdMet geldt, dan geldt ook nen2660:isDescribedBy, maar als nen2660:isDescribedBy dan geldt niet altijd nen3610:geregistreerdMet.

Met de kennis uit het bovenstaande bericht konden in de werkversie voorlopig de volgende semantische relaties gelegd worden, met als toelichting nen3610:geregistreerdMet :

ObjecttypenSemantischeRelaties -- ``` FysiekObject :: isBeschrevenDoor :: TijdlijnRegistratie FysiekObject :: isBeschrevenDoor :: TijdlijnGeldigheid FysiekObject :: isBeschrevenDoor :: Versie FysiekObject :: isBeschrevenDoor :: Levensduur InformatieObject :: isBeschrevenDoor :: TijdlijnRegistratie InformatieObject :: isBeschrevenDoor :: Versie ```

Met de kennis uit het bovenstaande bericht konden in de werkversie voorlopig de volgende semantische relaties gelegd worden, met als toelichting nen3610:geregistreerdMet :

Ok, wat mij betreft hermodelleren we de relaties dan ook. Laat het maar allemaal geregistreerdMet relaties worden. Dit moet dan ook wel in documentatie en de diagrammen opgenomen worden.

In de werkversie van IMBOR 2023 is de relatie nen3610:geregistreerdMet toegevoegd als:

semantische relatie in imborVoc_Termen;
als vervanger van imbor:isBeschrevenDoor in imborKern_K_ObjecttypenSemantischeRelaties voor TijdlijnRegistratie, TijdlijnGeldigheid, Levensduur en Versie;
als nen3610:refObjecttype in refModel_Objecttypen;
niet in refModel_Mapping als uitdrukkingIn van nen2660-2:isDescribedBy in NEN 3610 omdat dit een uitspraak is die m.i. in een projectierelatie tussen NEN 3610 en NEN 2660-2 thuishoort en niet in de relaties van IMBOR met andere modellen; de technische documentatie kan hier eventueel wel een meta-uitspraak over doen of verwijzen naar een (toekomstige) meta-uitspraak van de NEN en/of Geonovum;
wel in in refModel_Mapping als uitdrukkingIn van imbor:geregistreerdMet

Zonder me nog heel erg in NEN3610 te hebben verdiept: Wat betreft dit soort datum/datumtijd-attributen gaat onze voorkeur uit naar altijd datumtijd gebruik. In de praktijk worden vaak vragen gesteld over wie wat wanneer aangepast heeft bijvoorbeeld. Daarbij speelt tijd op de dag een belangrijke rol. Over het algemeen worden deze waarden door software gevuld, niet door de mens in een scherm. Dat maakt het des te makkelijker om gelijk de tijd mee te nemen.

Wat betreft voorstellen om aan te passen/verwijderen:

"mutatiedatum (kan eigenlijk verwijderd worden omdat dit afgeleid kan worden van tijdstipRegistratie)". Mee eens.
"levensduur (hangt samen met objectBegintijd en objectEindtijd, dus kan wellicht vervallen)." Mee eens. Dit leiden we nu al af en registreren we niet apart.
"technische levensduur (is eigenlijk iets waarvan de expert zegt hoe lang het meegaat)". Klopt, zou een vrij invoerveld moeten zijn. Integer.
"theoretisch eindjaar (zou dan wellicht ook objectEindtijd kunnen zijn)". Niet mee eens. Theoretisch eindjaar geeft aan wanneer een object "op" zou moeten zijn. Dus moment van uit de fabriek komen tot eind van beoogde levensduur zoals gesteld door fabrikant. objectEindtijd geeft aan wanneer het object ophoudt te bestaan. Dat gaat veel meer richting praktische eindtijd, lees de datum waarop een beheerder het object laat weghalen.

Wat betreft dit soort datum/datumtijd-attributen gaat onze voorkeur uit naar altijd datumtijd gebruik. In de praktijk worden vaak vragen gesteld over wie wat wanneer aangepast heeft bijvoorbeeld. Daarbij speelt tijd op de dag een belangrijke rol. Over het algemeen worden deze waarden door software gevuld, niet door de mens in een scherm. Dat maakt het des te makkelijker om gelijk de tijd mee te nemen.

Thanks @GreenpointAdviesPN Het is goed om te zien dat meeste conclusies die binnen deze impactvolle issue getrokken worden. Wat betreft de keuze voor xsd:date in sommige gevallen is dit omdat hierin zoveel mogelijk de standaarduitwerking van de NEN 3610 wordt gevolgd. Echter legt de NEN 3610 IMBOR in dit opzicht niet voor alle attributen restricties op. Mocht men expliciet behoefte hebben aan xsd:dateTime, dan kan dit. In het specifieke geval van objectEindtijd en objectBeginTijd wordt meestal niet verwezen naar een 'systeemtijd' dit zijn meer hoogover registraties. Daarom denken we dat xsd:date hier meer generiek is. Het staat in implementaties natuurlijk vrij om xsd:dateTime te gebruiken omdat xsd:date hieruit afgeleid kan worden.

"theoretisch eindjaar (zou dan wellicht ook objectEindtijd kunnen zijn)". Niet mee eens. Theoretisch eindjaar geeft aan wanneer een object "op" zou moeten zijn. Dus moment van uit de fabriek komen tot eind van beoogde levensduur zoals gesteld door fabrikant. objectEindtijd geeft aan wanneer het object ophoudt te bestaan. Dat gaat veel meer richting praktische eindtijd, lees de datum waarop een beheerder het object laat weghalen.

Hier wordt denk ik gereageerd op de initiële van deze issueopening door, maar die kan als achterhaald beschouwd worden. Zie https://github.com/Stichting-CROW/imbor/issues/1075#issuecomment-1464027218 voor de definitieve uitwerking.

Hierin staat opgenomen voor theoretisch eindjaar:

Redundant gegeven vanwege de berekende aard van het gegeven en behoort derhalve te vervallen.

Deze conclusie is getrokken omdat theoretisch eindjaar een jaartal is dat wordt bepaald op basis van het productiejaar/de objectbegintijd en de technische levensduur. Wijzigt die laatste, dan wijzigt theoretisch eindjaar eigenlijk mee; er is dus sprake van een afhankelijkheidsrelatie die maakt dat het karakter van theoretisch eindjaar dynamischer is dan wenselijk is voor IMBOR."

@RiX012 We moeten bespreken wat hier nog de openstaande actiepunten voor zijn.

Los daarvan heeft Registratie op dit moment nog geen eigen identificatie. De NEN3610 heeft dit ook niet, zie onderstaande afbeelding. Dit wijkt af van de huidige IMBOR-modellering van Registratie-informatie. De vraag is: is dit een probleem? Ik denk van niet, omdat Registratie geen InformatieObject is.

IMBOR 2025 implementeert de ‘temporele aspecten’ uit de bovenliggende standaard NEN 3610. Het gaat om de klasse ‘Registratie’ die (1) een TijdlijnRegistratie voor het vastleggen van digitale wijzigingsmomenten, (2) een TijdlijnGeldigheid voor het vastleggen van de tijdstippen waarop het digitale object een geldige representatie van de werkelijkheid is en (3) een Levensduur die het vastleggen van de begin- en eindtijden van het bestaan van een object faciliteert. Aan elk object met Registratiegegevens behoort ook een Versietoe. Daarnaast implementeert IMBOR de NEN 3610 in samenhang met de NEN 2660-2. Voor nen2660-2:PhysicalObject geldt dat TijdlijnRegistratie, TijdlijnGeldigheid, Levensduur en Versie van toepassing zijn, terwijl voor Voor nen2660-2:InformationObject alleen TijdlijnRegistratie en Versie gelden.

Finale wijzigingen: a. Alle attributen van Levensduur moeten datatype xsd:dateTime hebben. In principe is ook xsd:date een NEN 3610-conforme implementatie, maar eenzelfde lijn trekken voor al deze attributen voorkomt gebruikersverwarring. b. In lijn met de NEN 2660-2 objecificeert IMBOR zoveel mogelijk. Hiertoe wordt de klasse Registratie als een subklasse van Object beschouwd. Dus: Registratie isSubclassOf Object. Dit betekent dat Registratie ook een eigen identificatie krijgt. c. Om te zorgen dat Registratie ook een domein krijgt, wordt de eigenschap domein verplaatst van de klasse GeoObject naar de klasse Object. Dus: ‘domein isPropertyOf GeoObject’ wordt ‘domein isPropertyOf Object’

Er wordt verzocht deze issue, na een controle, te sluiten.

Er wordt verzocht deze issue, na een controle, te sluiten.

Na controle nog aantal aanvullingen en wijzingen:

Het lijkt logisch om Registratie een subklasse te maken van time:TemporalEntity. Dit zou in lijn zijn met de NEN2660-2. Maar omdat de uitwerking zoals de NEN3610 het doet, niet helemaal consistent is met de Time-Ontology EN Representatie ook niet past bij de definitie van Registratie lijkt het logischer om het een subklasse te maken van InformatieObject. Dan kan geregistreerdMet ook een rdfs:subProperty zijn van nen2660:isDescribedBy. De rest klopt.

[x] Registratie een subklasse maken van InformatieObject ~~- [ ] startNode een subproperty maken van nen2660:isDescribedBy (Kan dit in Access of moet dit in post-processing?)~~
[x] geregistreerdMet een subproperty maken van nen2660:isDescribedBy (Kan dit in Access of moet dit in post-processing?)
[x] In de mapping tabellen (ref*) moeten de URI's van NEN3610 toegevoegd worden (ala QUDT)

Goede reflectie om TemporalEntity buiten beschouwing te laten; ander zou dit eerst weer met de grondleggers van NEN 3610 overlegd moeten worden.

In de bovenstaande opsomming van taken bedoel je met startNode denk ik is geregistreerd met?

In de bovenstaande opsomming van taken bedoel je met startNode denk ik is geregistreerd met?

Jep thanks: geregistreerdMet

Bespreekpunt: er is geen URI voor geregistreerdMet

@RiX012 TijdlijnRegistratie en Versie moeten eigenlijk aan Object gerelateerd worden, zodat Activiteit en GeometrischeRepresentatie - net als Informatieobject - ook versies en registratiehistorie kunnen hebben.

@RiX012 TijdlijnRegistratie en Versie moeten eigenlijk aan Object gerelateerd worden, zodat Activiteit en GeometrischeRepresentatie - net als Informatieobject - ook versies en registratiehistorie kunnen hebben.

Op kunnen ze aan Object, maar Activiteit en Geometrische representatie zouden niet onder nen2660:Object moeten hangen. Dat ze Versie en TijdlijnRegistratie krijgen is ok.

Actie: controle door @RiX012 en daarna definitief afsluiten.

Stichting-CROW / imbor