Levensfasen - uitwerking 3 - Plan (document) en gepland object

[pmaria]

Deze modelleringen zijn uitwerkingen o.b.v. deze casus waarbij er voor objecttypes die onderhevig zijn aan planning een plan(document) als object geïntroduceerd wordt VerhardingPlan.
Dit plan verwijst naar een gepland object wat een een "geplande" variant van het object wat het onderwerp van het plan is.

[pmaria]

Alternatief a - Verhardingsplan en hergebruik van objecttype met dezelfde id

In deze uitwerking wordt er naast het objecttype Verharding een objecttype VerhardingPlan geïntroduceerd. Deze representeert het daadwerkelijke plan en refereert aan een geplandObject. Het gepland object is een instantie van Verharding, maar met de geplande gegevens.
Met behulp van de versie aanduiding op de bijbehorende Registratiegegevens kan onderscheid gemaakt worden tussen de instanties.

In deze uitwerking is het ook mogelijk om de het alternatieve plan mee te nemen in de data.

Voordelen (wordt bijgewerkt adhv discussie)

• Kan complexe situatie aan: meerdere plannen per object
• Geen extra schaduw objecttype nodig
• Plan biedt aanknopingspunt voor "plan-informatie"
• ?

Nadelen (wordt bijgewerkt adhv discussie)

• Relatie tussen geplande verharding en verharding is geen expliciete relatie (afspraak via id)
• Objecten van zelfde type met zelfde id kunnen gelijktijdig bestaan (weliswaar te onderscheiden via registratiegegevens.versie)
• Statussen moeten obv gegevensregels onderscheiden worden
• ?

[pmaria]

Alternatief b - Verhardingsplan en gepland object

In deze uitwerking wordt er naast het objecttype Verharding een objecttype GeplandeVerharding geintroduceerd, alsook een objecttype Verhardingsplan die deze aan elkaar verbindt. Het VerhardingPlan representeert het daadwerkelijke plan en refereert aan een geplandObject van het type GeplandeVerharding.


In deze uitwerking is het ook mogelijk om de het alternatieve plan mee te nemen in de data.

Voordelen (wordt bijgewerkt adhv discussie)

• Kan complexe situatie aan: meerdere plannen per object
• Statussen zijn natuurlijker gescheiden
• Plan biedt aanknopingspunt voor "plan-informatie"
• Zelfde id voor gepland object en object kan nog gebruikt worden, maar is niet noodzakelijk
• ?

Nadelen (wordt bijgewerkt adhv discussie)

• Een plan “schaduw-objecttype” per objecttype onderhevig aan planning is nodig (?: is dit een nadeel?)
• 3 objecttypes nodig
• ?

[pmaria]

Hierbij nog een voorbeeld om aan te tonen dat met het modelleren van een expliciet plan (document) het ook mogelijk maakt om daar specifieke gegevens over uit te drukken. In dit geval een specifieke levenscyclus van het plan.

[lvdbrink]

Uit gesprek met de inhoud werkgroep maakte ik op dat het plandocument geen beoogd onderdeel van de SOR is.

[RuudKathmann]

Deze werkwijze met een plandocument sluit niet aan op de beoogde werkwijze van de SOR, omdat juist de intentie is om minder dan bijvoorbeeld bij de huidige BAG te werken met formele brondocumenten.

[lennartvanbergen]

Nadeel: is eigenlijk zoals 2, maar met expliciete relaties. Deze leveren echter in de implementatie van een registatie lastige items op. Elke relatie moet een eigenaar hebben, en elke wijziging van de relatie moet in 1 van de 2 objecten opgenomen worden. Dat leidt tot extra versies van objecten, dat kan alleen aan de plan object kant. Dan kan het wel.

Open: Als het plan object een andere identificatie heeft, dan moet je de identificatie reserveren ... hoe, waar?

[lvdbrink]

Aanvullingen vanuit overleg 15 april:

• Ruud en Dick bevestigen: brondocumenten zijn binnen scope van de SOR dus het modelleren van een apart uitgesplitst plan (een specifiek soort brondocument), plus een gepland object, is wel denkbaar.
• functioneel: gebruikers willen weten hoe het object er in de toekomst uit ziet. En willen nadere documentatie over het geplande object, bv een vergunning of luchtfoto, kunnen achterhalen. Via de informatie in het brondocument moet dit kunnen.
• NB: Pano heeft bij het uitwerken nog niet heel hard nagedacht over richting van relaties.