Explore and develop the right way of performing automatic versioning

[zozlak]

Automatic versioning brings in context of the ARCHE-with-ACDH-schema brings quite a few challenges:

• Should the old version keep its parent? If it does, we end up with two resources with same filename in same collection which is problematic for dissemination services (including GUI). If if does not, the old resource is not compatible with the ARCHE-ACDH schema (as the schema requires acdh:Resource to have exactly one acdh:isPartOf).
• How to handle god damn acdh:hasCmdiPid keeping the arche-lib-ingest schema agnostic?
• What about version numbers creation? (which could help distinguishing between versions if we keep all of them in the same collection)
• How to handle acdh:hasNextItem? Probably the old version should be excluded from the next item list and replaced in it with the new version.
• Should acdh:hasVersionInfo with a version number be automatically created?

As for the library architecture it probably means the Indexer should allow to register an external metadata preprocessing handle taking the to-be-versioned resource metadata and returning old and new resource metadata. In such an architecture it will be higher level library (e.g. arche-ingest) responsibility to provide a proper metadata handler (e.g. "Peter's versioning handler")

[csae8092]

IMHO the most important use case for versioning is that, if somewhere an already existing handle-pid is used (in some publication, or from another application); the handle should resolve to this version (read the old version) of the binary; if the gui-diss services is requested, the user should get directed to the metadata of the old-version. BUT in the resource's detail view, there should be a big disclaimer pointing to the new version

• acdh:isPartOf: I think it makes not much sense to keep the old version(s) in the same collection as the new version; therefore my first idea was to create some generic collection, called something like "old versions" and add all "old" resources into this collection, no matter the original context; but I'm not sure how to deal with all the mandatory properties like License, Owner, ...
  • maybe a new class OldVersionOfResource could make things easier in regards of doorkeeper/schema restrictions?;
• acdh:hasCmdiPid: I frankly don't know anything about this CMDI thing though I'm pretty sure that only very view people actually care
• acdh:hasVersionInfo I don't see any speaking against it

[zozlak]

@csae8092 are you using acdh:hasNextItem in collections which require this kind of versioning?

[zozlak]

@csae8092 and in general what about other resources pointing to the old version (something like acdh:documents). Should these references be copied to a new version, moved to a new version or just stay with the old version or should the behavior be different for different properties?

[csae8092]

@csae8092 and in general what about other resources pointing to the old version (something like acdh:documents). Should these references be copied to a new version, moved to a new version or just stay with the old version or should the behavior be different for different properties?

moved to the new version