begin- en endLifespanVersion toevoegen aan UtilityNetworkElement

[NielsGabriels-GIM]

Ik ga ervan uit dat UtilityNetworkElement (Nutsvoorzieningnetwerkelement) overerft van NetworkElement uit het Generiek Netwerk Model. Klopt dat? Zo ja, dan moeten volgens mij ^beginLifespanVersion en ^endLifespanVersion toegevoegd worden aan UtilityNetworkElement.

[GeertThijs]

Versioneringsinfo voegen we nooit toe aan een applicatieprofiel (AP), komt pas aan de orde in een implementatiemodel (IM):

• Bij INSPIRE lopen AP en IM wat dooreen, daarom dat het wel daar te vinden is.
• Version volgens INSPIRE slaat op de historiek van de data, niet de historiek van de objecten zelf. Het eerste noemen we TransactionTime (wanneer is de data veranderd), het tweede wordt ValidTime (wanneer is er iets aan het object veranderd) genoemd.
• Validtime zit momenteel wel in het AP: UtilityNetworkElement.validFrom en .validTo. Daarmee kan je de ValidTime ve object weergeven: wanneer ontstond de kabel op terrein, wanneer werd hij uit de grond verwijderd.
• Of zelfs: wanneer veranderde iets aan de kenmerken van de kabel (al dan niet met behoud van id, indien met behoud krijg je ahw een tweede versie van de kabel, indien een nieuw id ontstaat krijg je een nieuwe kabel).
• In het IM voeg je wel iets als begin/endLifespanversion toe, maar dat wisselt van platform tot platform. Bij ontsluiting via LDES bvb wordt gewoon een timestamp toegevoegd (die impliciet in combinatie met het objectid het versienummer wordt). Terwijl in een SQL databank bvb kan de vereiste zijn dat er een timestamp moet zijn die het begin vd versie aangeeft en ook een voor het einde (vergemakkelijkt bepaalde querys).
• Kortom: transactieTijd is iets platformafhankelijk en hoort dus niet thuis in een AP.