Ensuring accessibility and integrity of datasets in ARChive publications

[Thyra]

While exploring the ARChive today, I found a "published dataset" (https://doi.org/10.60534/qsh62-7p088) where the link to the actual ARC/data gave me a 404 error (the ARC is private) and after asking about it on the Data Steward matrix chat, it turns out there is a somewhat systemic problem underneath:

• The ARChive publication, which the DOI points to, contains only meta-data (title, authors, list of files in the ARC, ...) and points to a repo on the PLANTdataHUB for the actual ARC/data.
• This repo, however, can of course be updated with further commits which would make the metadata on ARChive outdated
• Worse still, the repo can also be deleted, transferred, or set to private so that the ARChive publication just points to nothing and becomes IMHO really quite useless.

Solutions

• A helpful and comparatively easy improvement would be to have the ARChive publication point to a specific commit rather than just the repo itself so that at least a simple, innocent commit to the repo after publication does not cause the ARChive publication to fall out of sync. It is not a full solution, though, because it does not address the deleting/transferring/making-private of the repo and also offers no protection against force-pushing/rebasing the repo with a changed commit.
• The only clean solution I can think of is a frozen copy of the full ARC at time of publication, i.e. the Zenodo approach. This is a problem for huge datasets but as @TetraW pointed out, perhaps there is a way to leverage the git LFS infrastructure so that large files do not need to be copied (e.g. by creating a read-only fork of the repo and thereby keeping the LFS pointers alive even if the original repo is deleted; I don't know enough about git LFS to say if it works that easily but it sounds like it should be possible somehow)

Why I think this is important

People are going to write things in their manuscripts like "All data and code used in this manuscript are freely accessible at DOI foobar". That is not true if the DOI publication is in reality just the metadata (I was actually a bit irritated when I learned that today, it almost feels intentionally misleading when it's always framed as a "data publication") and if I was an editor or reviewer for that paper, I would not be content unless the accessibility and integrity of the data was ensured in some way.

[Thyra]

Very closely related (if not even duplicate) to #9 🤦 . Well at least you can see it's clearly still an issue...

[TetraW]

Hey, Git LFS functions (as we have configured it) by storing a dataset in S3 storage. The name however is not the human-readable name of the dataset, but a shasum. If I am not mistaken, also the file size, which would make this even more robust. In a repository only a pointer file, containing the shasum and the file size, are stored. If another file with the same size and shasum is about to be uploaded into the S3-Storage, it is assumed that these files are the same and only a pointer file is created. So we can assume there are no duplicates in the S3 backend, even if we fork repos or upload the same dataset multiple times. If a reference is removed from a repo, the object is not removed automatically. There has to be some kind of garbage collection for this to happen. But I do not know the details here.

There is also a solution in discussion using RO-Crates for Metadata as well as directly accessible S3 references for the datasets. But I do not know more details about this. @Thyra Thanks for moving this here :)