Versienummering dataset en datamodel is niet bepaald

[redmer]

De versienummering van de dataset en het datamodel is nog niet bepaald.

Ik stel mij voor dat het datamodel zelf weinig veranderingen zal doormaken gedurende het gebruik ervan. De dataset wordt samen met IMBOR geüpdatet en zal dientengevolge halfjaarlijks een nieuwe versie krijgen.

Hoe wijzigingen aan de dataset bekend worden gemaakt en in de dataset zitten, valt buiten de scope van deze issue.

Datamodel

Voor het abstracte datamodel verwacht ik iets als v1.0.0, met typfoutjes (bugfix) hersteld in v1.0.1, uitbreidingen in een v1.1.0, terwijl verwijderingen en wijzigingen leiden tot v2.0.0.

Dataset

IMBOR is continue ontwikkeling en daarom ook de OTL BIM Pro. Bij deze ontwikkelingen worden voorstellen vastgesteld (IMBOR noemt dit gepubliceerd c.q. bevroren) voor een bepaalde periode. Voorstellen zitten daarmee in de dataset, maar kunnen op elk aspect nog wijzigen.

Voor de afnemers van de dataset kunnen we twee soorten bestanden beschikbaar stellen.

1. De volledige historische versie van IMBOR, inclusief voorstellen en niet-meer-geldige waardes.
2. De versie van IMBOR geldend op een datum. Deze bevat dan alleen vastgestelde onderdelen, zonder niet-meer-geldige waardes. Dit is ook handig voor archivering en bij contractering.

Versies van de dataset geldig-op-een-bepaalde-datum krijgen een versielabel mee van de datum op sorteervolgorde: bijvoorbeeld v20190801 voor de versie geldend vanaf 1 aug. 2019.

De volledige historische versie van IMBOR kan naast voorgenoemde datumstijl, ook versienummering krijgen parallel lopend met IMBOR. IMBOR publiceert 1-2x per jaar een nieuwe versie, e.g. 2019-1, 2019-2, 2020-1. Dan wordt de versienummering v2019.1.0, v2019.1.1, v2019.2.0, v2020.1.0 waarbij ook kleine wijzigingen (typfouten) tussendoor kunnen worden doorgevoerd.

[RiX012]

Gebaseerd op de memo ( Queries op IMBOR en versiebeheer (002).docx) van @ElisabethKloren waarin twee use cases worden genoemd:

1. Met IMBOR als basis, een eigen OTL maken;
2. De OTL aanpassen, omdat er wijzigingen in IMBOR zijn doorgevoerd;
   ... en vier soorten query* vragen:

• MVQM (use case 1)
• MSVQ (use case 1)
• DMQ (use case 2)
• SDQ (use case 2)
  ... met daarnaast het feit dat dit een allereerste release betreft die naar alle waarschijnlijkheid grondig geoptimaliseerd kan worden, lijkt het logisch om op dit moment voor een stabiele maar relatief eenvoudige manier van versiebeheer te kiezen.

1. De versienummering van @redmer lijkt verstandig en kunnen we mee doorgaan.
2. Daarnaast is het voorstel om periodieke dumps te maken die beschikbaar worden gesteld als file download (op een website of GitHub) en wellicht een endpoint. Hiermee worden MVQM en MSVQ en daarmee use case 1 afgedekt (overigens zijn HVMQ en HVSQ ook mogelijk).
3. De DMQ en SDQ delta queries zijn lastiger. Hiervoor moet de delta inzichtelijk gemaakt worden. Vooralsnog gaan we bekijken of de Changeset ontology makkelijk te implementeren is. Dit is echter wel iets voor de vervolg fase, want nu ronden we af met een 'stabiele' versie die vooralsnog alleen in test projecten gebruikt gaat worden. Use case 2 lijkt daarmee pas in het vervolg belangrijker.
   @ElisabethKloren @redmer @NielsHoffmann @nreyngou Eens met deze afwegingen?

*Afkortingen als genoemd in: Versiebeheer in LD - CROW (20191220 Review versie).pdf

[redmer]

Ik heb een versienummer toegevoegd aan de ontologie.

Bij een update van de ontologie moet ook https://github.com/Stichting-CROW/imbor/blob/master/data/transformaties/002%20Voeg%20versieinformatie%20toe.rq geüpdatet worden met het nieuwe versienummer.