Versioning Works

[srerickson]

This is a placeholder for discussion of Work versioning in ScholarSphere 4. Generally, we need to define the parts of a Work that are versioned (i.e. changing them constitutes a new version) and the parts that are not. The "parts" here include things like file contents, filenames, and metadata.

A closely related but potentially distinct concern is DOI versioning. The approach to Work/DOI versioning we adopt should correspond as much as possible to common patterns for Work/DOI versioning used by other repositories—to the extent common patterns exist. Following Zenodo's pattern, for example, a Work with a DOI generated by ScholarSphere gets a new DOI for each version. (Note that not all ScholarSphere Works have DOIs and not all Work DOIs in ScholarSphere were generated/managed by the system).

Zenodo's versioning pattern is as follows:

• "Data files are versioned. Records are not versioned."
• New versions are created by either adding new files or removing existing files from the previous version. (If you try to make a new version by removing a file and re-uploading it, even with a different filename, the new version cannot be saved—the error message reads, "New version's files [contents] must differ from all previous versions").
• Each version has its own editable metadata fields—you can change the title of version 1 without affecting the title of version 2. (The Work's title is the title in the last version).

Dryad's versioning pattern is as follows [link]:

• A dataset's metadata and files are associated with a version which cannot be changed once the version is published.
• New versions, with different metadata and files, can be created as needed.
• New versions do not generate new DOIs. There is only one DOI for each work.

There are significant differences between these approaches:

• Dryad does not support separate DOIs for versions but Zenodo does.
• Dryad's versions are immutable at both the file and metadata level; Zenodo's versions are only immutable at the file level (e.g. you can change the title of a version even after it is created).

There is at least one important similarity. In both cases, a work's metadata is linked to the work through a version. This means that metadata are versioned in a broad sense (metadata can change between versions) but not necessarily in a narrow sense because, at least in the case of Zenodo, a change in metadata alone does not constitute a new version.

Questions we need to address:

• Do we want separate DOIs for each version (like Zenodo) or just one DOI for the work (like Dryad)?
• Do we want versions to have mutable metadata (like Zenodo) or immutable metadata (like Dryad)?

[cynhudson]

What are other institutions doing?

[awead]

Capturing a bit of discussion @srerickson and I had in Slack: From a modeling perspective, the metadata will be stored with each version of the work. So each version's database record has its own instance of metadata. However, changing that metadata can be controlled any way we see fit. So it's possible under certain circumstances to have a change in a work's metadata require a new version, i.e. if it's published. Alternatively, a different set of circumstances would allow a work's metadata to be edited directly without the need for a new version.

[srerickson]

Figshare's versioning approach:

Provided it is a public figshare item, the following actions will trigger versioning when saving publicly:

    Modifying the title 
    Add/edit/remove author/s 
    Adding new files 
    Removing files 
    Replacing files 
    Removing confidentiality from files 
    Removing the metadata only flag and uploading files 
    Replacing the link associated with a linked item 

[srerickson]

Closing this issue and moving discussion here.