Versioning specifications
This issue is for discussing the specifications and workflows for versioning of items.
Aim of versioning
We like to have one single official curated item that is presented to the public. This item may be based on curation tasks like correcting and enriching of values/properties or merging of same items coming from different sources. Every curation task creates a new single official curated item, whereas the former versions are still available - but not to the public - due to reconstructing the curation process.
Identifier for versioning
The single official curated item should be always available under the same identifier (this is the six-letters/digits-identifier that is discussed here sshoc-marketplace-backend#29 (closed)). This item and all the former versions also have an internal identifier (running number given by database = primary id key).
Reconstructing version history
In curation we like to have the history of an item. It should show what happend so far for an item in terms of curation. This curation history may be also shown to the public (like Wikipedias "Revision history", e.g. https://en.wikipedia.org/w/index.php?title=Cox%27s_Orange_Pippin&action=history).
Showing context of item in terms of version history
We also like to show to the public the context of an item, e.g. how does it come into the SSHOC MP. This means we need a way to show on the detail page of the single official curated item a summary of important curation tasks. An example is merging items from different sources: at the single official curated item it should be highlighted from which sources this item is created. This means either we always automatically add such information to the new version of an item or we have a way to traverse through the version history when showing a detail page.
Information that is not part of the versioning
For reasons of simplicity it seems to be necessary to define some information, that is excluded from the versioning. One example are comments: they should be bound always to the current version of an item and not to former versions (even if the information in the comment may refer to a former version). Another example are relations to other items: it seems to make things very complicated, if we add every change of references to the versions of an item, instead it may be more pragmatic to allow only relations to the official curated items (using the six-digits/letters-identifiers here) - see also sshoc-marketplace-backend#29 (comment 182876).
This is a first draft for the specifications of the versioning. As there is frontend, backend, data model, user experience involved, please be free to add your views (and other people that may be interested into this topic): @matej.durco @lbarbot @mkozak @stefan.probst @frank.fischer01 @ymoranv @swolarz