Stichting-CROW / imbor

Een informatiemodel en objecttypenbibliotheek (né ontologie) voor assetbeheer van de openbare ruimte
https://www.crow.nl/imbor
9 stars 2 forks source link

NEN3610 Temporele Aspecten volledig consistent doorvoeren in IMBOR #1075

Closed RiX012 closed 1 month ago

RiX012 commented 1 year ago

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:

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:

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:

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:

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:

  1. waarom dit attribuut er in deze hoedanigheid is (en is in gekomen),
  2. of het attribuut kan vervallen,
  3. of het attribuut afgeleid kan worden van andere attributen,
  4. 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):

Impact

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

wjtmollema commented 1 year ago

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)

  1. 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.
  2. 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.
  3. 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.
  4. Voorgestelde herziening (incl. motivatie): N.v.t. vanwege argumentatie voor vervallen onder punt (2).

Datum memo datum memo (maakt onderdeel uit van Memo)

  1. 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.
  2. 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.
  3. Afleidbaarheid: datum memo is afleidbaar uit de invulling van de tijdstipRegistratie uit de oorspronkelijke versie van Memo in de TijdlijnRegistratie.
  4. 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)

  1. Reden tot opname in IMBOR: Dit attribuut is in IMBOR opgenomen om de datum waarop een domeinwaarde van een attribuut is ingewonnen te registreren.
  2. 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.
  3. Afleidbaarheid: Het gegeven is niet logisch afleidbaar uit een ander IMBOR- of NEN3610-temporeel gegeven.
  4. 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)

  1. 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.
  2. Mogelijkheid tot vervallen (incl. motivatie):
  3. 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.
  4. 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)

  1. 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.
  2. 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.
  3. 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.
  4. 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)

  1. Reden tot opname in IMBOR: Voor bomen is het van belang te weten hoe oud ze zijn of dit te schatten.
  2. 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.
  3. 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.
  4. 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)

  1. 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?').
  2. 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.
  3. 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.
  4. 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)

  1. 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.
  2. Mogelijkheid tot vervallen (incl. motivatie): Het is niet wenselijk om dit
  3. Afleidbaarheid: mutatiedatum is afleidbaar uit de tijdstipRegistratie van de meest actuele versie van het object in de TijdlijnRegistratie.
  4. 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)

  1. 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.
  2. 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.
  3. 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).
  4. 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)

  1. 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.
  2. 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.
  3. 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.
  4. 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)

  1. 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.
  2. Mogelijkheid tot vervallen (incl. motivatie): Dit gegeven kan niet komen te vervallen omdat het niet redundant is bij het gebruik van NEN3610-Registratie-informatie.
  3. 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.
  4. 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)

  1. 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.
  2. Mogelijkheid tot vervallen (incl. motivatie): technische levensduur is een gegeven uit een andere NEN-norm en mag als zodanig niet vervallen.
  3. Afleidbaarheid: Het attribuut is niet afleidbaar uit NEN3610-Registratie-informatie.
  4. 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)

  1. 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.
  2. 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.
  3. 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.
  4. Voorgestelde herziening (incl. motivatie): Er zijn geen wijzigingen benodigd.

Vernieuwingsdatum vernieuwingsdatum (maakt onderdeel uit van Bord)

  1. Reden tot opname in IMBOR: Op dit moment is dit attribuut alleen van toepassing bij de klasse Bord.
  2. Mogelijkheid tot vervallen (incl. motivatie): Dit attribuut kan vervallen op basis van de sterke mate van afleidbaarheid.
  3. 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.
  4. 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)

  1. 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.
  2. 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.
  3. 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.
  4. Voorgestelde herziening (incl. motivatie): Er zijn geen wijzigingen benodigd, vanwege de conclusie van punt (3).

Verwijderdatum verwijderdatum (maakt onderdeel uit van Registratie-informatie)

  1. 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).
  2. 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.
  3. 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.
  4. Voorgestelde herziening (incl. motivatie): N.v.t. vanwege argumentatie voor vervallen onder punt (2).
RiX012 commented 1 year ago

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.

RiX012 commented 1 year ago

Korte conclusie:

Datum memo datum memo (maakt onderdeel uit van Memo)

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

RiX012 commented 1 year ago

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.

RiX012 commented 1 year ago

Bij nader inzien gaan we de volgende aanpak hanteren:

  1. @wjtmollema en @RiX012 gaan een afspraak plannen met Geonovum om te toetsen hoe de NEN3610 temporele aspecten goed in IMBOR verwerkt zouden moeten worden
  2. We gaan generieke uitspraken doen hoe NEN3610 temporele aspecten toe te passen
  3. We gaan bovenstaande attributen langs met de kennis uit de vorige twee punten om dit consistent in IMBOR door te voeren
  4. We toetsen de werkwijze en impact bij de softwareleveranciers en voeren op basis daarvan de wijzigingen door
RiX012 commented 1 year ago
  1. @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: image

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.

wjtmollema commented 1 year ago

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

RiX012 commented 1 year ago

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.

wjtmollema commented 1 year ago

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:

  1. Validatie door vertegenwoordigers van NEN 3610;
  2. Feedback van softwareleveranciers;
wjtmollema commented 1 year ago
  1. @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: image

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.

RiX012 commented 1 year ago

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.

RiX012 commented 1 year ago

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?

wjtmollema commented 1 year ago

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 :

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns="http://www.w3.org/TR/REC-html40">

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

RiX012 commented 1 year ago

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.

wjtmollema commented 1 year ago

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

GreenpointAdviesPN commented 1 year ago

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:

RiX012 commented 1 year ago

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.

RiX012 commented 1 year ago
  • "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."

wjtmollema commented 4 months ago

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

image

wjtmollema commented 3 months ago

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

wjtmollema commented 3 months ago

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

RiX012 commented 2 months ago

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.

wjtmollema commented 2 months ago

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?

RiX012 commented 2 months ago

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

Jep thanks: geregistreerdMet

wjtmollema commented 1 month ago

Bespreekpunt: er is geen URI voor geregistreerdMet

wjtmollema commented 1 month ago

http://modellen.geostandaarden.nl/def/nen3610-2022#registratiegegevens toegevoegd.

wjtmollema commented 1 month ago

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

RiX012 commented 1 month ago

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

wjtmollema commented 1 month ago

Actie: controle door @RiX012 en daarna definitief afsluiten.