Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Using ARKs for version control, initial draft proposal #887

Open
emmetaobrien opened this issue Apr 12, 2024 · 0 comments
Open

Using ARKs for version control, initial draft proposal #887

emmetaobrien opened this issue Apr 12, 2024 · 0 comments
Labels

Comments

@emmetaobrien
Copy link
Collaborator

emmetaobrien commented Apr 12, 2024

Intended functionality:

  1. a dataset version changes when the data provider specifies it should.
  2. a new ARK is generated when dataset version changes.
  3. the ARKs of previous versions link to the appropriate GitHub commit.

System needs to support the following use cases:

A) Dataset is updated with new scientific content.
B) Technical updates (e.g. extra properties added to DATS.json for CONP internal purposes) that make no difference to scientific content of dataset.
C) Removal of data from all versions of dataset (e.g. patients withdrawing from a study).

Proposed implementation:

Define somewhere to store archived ARKs for each dataset. Could be something like extraProperties=>archivedVersions in the DATS.json, an additional config file, or some other location. Subsequent text refers to this as archivedVersions, this is a placeholder.

Handling case A:

This function is triggered when a user changes an existing value in the version field. (I believe population of the version field on initial data submission can remain as currently implemented; some CONP datasets refer to concluded projects and no further updates are envisioned.)

workflow:

  • prepare archival data for previous version of dataset (version label, ARK, relevant github commit, date?, potential other information??)
  • check for existence of archivedVersions for this dataset
  • if NO, initialise archivedVersions and write archival data as first entry
  • if YES, add archival data as another entry in archivedVersions
  • save DATS.json with updated version number (as currently happens)

interface changes:

  • if archivedVersions exists for dataset, display one line for each entry containing the archival data. (Decide where in the dataset page to show this, and how.)

Case B will be carried out by CONP developers on a case-by-case basis and is generally not envisioned as updating versioning at this time.

Case C requires retroactive adjustments to all versions of a dataset that we serve. @samirdas suggested that removing the data from the underlying dataset sufficed, though this will leave broken links and error messages in a Datalad download.

This is very preliminary, feedback much appreciated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

7 participants