Levensfasen - uitwerking 1 - complete levenscyclus in 1 object

[pmaria]

Deze modelleringen zijn uitwerkingen o.b.v deze casus waarin de complete levenscyclus altijd in hetzelfde object wordt gemodelleerd. Zo kan hetzelfde object bijv de cyclus bestaand – verbouw gepland – bestaand doorgaan.

[pmaria]

Alternatief a - planstatus direct zichtbaar

In deze uitwerking wordt, op de datum waarop er een plan is voor de verbouw van de verharding, een nieuw voorkomen van de verharding geïnstantieerd met de geplande status. Omdat de geplande verbreding nog niet in de werkelijkheid aanwezig is wordt de geometrie nog niet aangepast. Wanneer het object daadwerkelijk verbouwd is ontstaat een nieuw voorkomen met de gewijzigde geometrie en de status bestaand.

Voordelen (wordt bijgewerkt adhv discussie)

• Informatiemodel is simpel
• Object houdt dezelfde identificatie door de gehele cyclus
• ?

Nadelen (wordt bijgewerkt adhv discussie)

• Kan de geplande staat van het object niet zien
• Kan niet meerdere alternatieve plannen aan
• Statussen zijn lastig onder te verdelen in "gepland" "aanwezig" "afwezig"
• ?

[pmaria]

Alternatief b - plan als toekomstmutatie

In deze uitwerking wordt voor een geplande wijziging een toekomstmutatie gedaan. Hierbij wordt zo goed mogelijk geschat op welke datum het object er anders uit zal zien (in dit geval een verbreding van de verharding). Er wordt een voorkomen gecreëerd die op die datum in de toekomst geldig wordt met status Verbouw gepland en de aangepaste geometrie. Wanneer de werkzaamheden daadwerkelijk zijn voltooid wordt dit voorkomen afgesloten en ontstaat er een nieuw voorkomen met de nieuwe situatie met status Bestaand.

Voordelen (wordt bijgewerkt adhv discussie)

• Informatiemodel is simpel
• Object houdt dezelfde identificatie door de gehele cyclus
• Geplande gegevens zijn wel in te zien
• ?

Nadelen (wordt bijgewerkt adhv discussie)

• Kan niet meerdere alternatieve plannen aan
• Bij alleen interesse in gerealiseerde objecten wordt bevraging complex
• Niet met 1 prikmoment (peildatum) kunnen zien dat er een plannen zijn voor bestaande objecten
• ?

[lvdbrink]

Nadeel lijkt mij dat bij beide bovenstaande varianten het niet mogelijk is om zowel de huidige als de geplande geometrie te zien.

[pmaria]

Op zich is dat in alternatief b wel mogelijk, alleen niet met hetzelfde "prikmoment". Je moet dus tijdreizen wil je een geplande geometrie zien.

[RuudKathmann]

Deze beschrijving komt ons inziens niet overeen met de beschrijving in het conceptueel model dat nu ter consultatie ligt.
Deze beschrijving komt het meest overeen met de situatie dat sprake is van een kleinere mutatie, waardoor er geen afzonderlijk nieuw "planobject" wordt gemaakt naast het bestaande object.
Wel wordt het bestaande object gemuteerd.
De actuele status wordt gemuteerd naar "verbouw gepland". Bij deze status hoort inderdaad nog de bestaande geometrie.
Tegelijkertijd wordt ook de toekomstige situatie vastgelegd met de toekomstige geometrie en de status "bestaand".
Deze toekomstmutatie krijgt daarbij een beginGeldigheid in de toekomst.
Beide vormen van geometrie worden dus wel vastgelegd, maar zijn nooit gelijktijdig geldig.

[lennartvanbergen]

Voor mij valt deze functioneel af, omdat het niet meerdere statussen tegelijk aankan. Er is een apart plan object nog nodig voor sommige situaties.

[PalmJanssen]

Wil toch nog iets nieuws in brengen als variant op deze versie.

NEN 3610 heeft voor de identificatie een getrapte uniciteit. Van land, naar domein, naar object. Maar er zit ook nog een versie-attribuut in. In feite is dat uniciteit binnen een ID, namelijk versies van een object met eenzelfde ID. NEN 3610 zegt dat er niet tegelijkertijd twee versies van een object geldig mogen zijn. Begrijpelijk. Maar als je dat eens loslaat? Een versie kan dan een andere representatie van het zelfde object zijn op het zelfde moment. Meerdere versies zijn dan meerdere representaties van hetzelfde object, eventueel allemaal op het zelfde moment. Als je wilt weten wat de versies betekenen kijk je naar het statusattribuut (en alle andere attributen). Als je wilt weten wanneer het informatieobject geldig is of wordt kijk je naar de tijdlijngeldigheid.

Op zich heb je dan een krachtig maar eenvoudig model. Alleen moet je oplossen hoe je identificatie en versie aan elkaar koppelt. En hoe versies weten dat ze bij dezelfde ID horen.

[lvdbrink]

@PalmJanssen jouw suggestie hebben we in #29 uitgewerkt. Of bedoel je wat anders?

[PalmJanssen]

Toch iets anders. In deze variant kunnen er meerdere instanties van 1 object en 1 objecttype tegelijk bestaan en in de registratie opgenomen zijn. Ze hebben ook het zelfde id, maar wel een andere versie. Aan de status attributen kan je zien wat er aan de hand is en aan de temp attributen wanneer ze geldig zijn in de werkelijkheid (nu of in de toekomst). Het lijkt wat dat betreft ook op de variant van Rik: meerdere representaties tegelijkertijd. De uitdaging is wel om versie een optioneel deel van de identificatie te maken. Opzich doen we dat hier en daar al maar dit is een meer structurele manier.

[RiX012]

Ja inderdaad. Dit is een andere oplossing voor de 'representatie' die ik nastreefde. Ik vind het wel een elegante oplossing. En ben het met Paul eens dat dit al hier en daar gedaan wordt maar dan niet-structureel, en niet altijd even expliciet. Als we hier een fix voor kunnen vinden zou dat mijn view op representatie voldoen recht doen.

[pmaria]

@PalmJanssen vanuit jouw beschrijving vind ik het lijken op #33 waarin je middels de status eigenschap op Registratiegegevens-niveau kunt aanduiden dat iets een plan is. In jouw voorstel, als ik die goed begrijp, zou je dat onderscheid met een versie string onderscheiden. Het gebruik van de versie om deze semantiek te duiden vind ik persoonlijk te veel conventie en semantiek stoppen in een identifier.