What is an editgroup?

An editgroup is a set of entity edits, bundled together into a coherent, reviewable bundle.

Make changes to entities
For review and feedback from others
Changes added to catalog
Status Merged (Changelog #5753782)
Editor j.sprinz
Description deduplication

All Entity Changes

Release Edits (2)

Work Edits (1)

Container Edits (0)

Creator Edits (0)

File Edits (0)

File Set Edits (0)

Web Capture Edits (0)


Comments and Annotations

j.sprinz at 2022-02-15 11:10:11

there have been two DOIs created, unfortunately, hence the duplicate import. marked the non-canonical one as superceeded, pointed to the same release, and deleted the duplicate release. hope that's fine.

bnewbold-archive Admin at 2022-02-16 01:21:54

The way we handle this sort of situation is to "group" the two release entities under a single 'work' entity.

At a minimum, one of the releases should be updated to have the work_id of the primary/canonical release, and then the now-empty work should be redirected to the other work.

At the same time, it might be worth updating one or both of the release entities with release_type (as you have here), publication stage, etc, to indicate what the difference is between the two releases.

j.sprinz at 2022-02-16 08:52:07

Alright, added the work redirect. Not sure what to put as publication stage for the non-canonical release, none of the values seem appropriate. The thing is, the non-canonical doi was erroneously generated by a library repository after the work had already been published and fitted with a doi by the publisher. So it is not exactly updated, or retracted. It just represents an additional reference to the same work.

j.sprinz at 2022-02-16 08:54:09

(this is editgroup also affected by https://github.com/internetarchive/fatcat/issues/92 for the record)

bnewbold-archive Admin at 2022-02-17 03:13:49

Yeah, in theory DOIs are supposed to be one-per-work, but there are a number of situations where this ends up not happening correctly. One I have seen is a small/informal publication posting papers to zenodo.org to get DOIs (and for hosting/preservation). Then later the publication becomes more formal or gets more resources, and switches to OJS or some other platform, and generates new DOIs. This results in multiple DOIs for the same paper; in theory it should be possible to transfer the old/existing DOIs away from the hosting platform, but that seem to happen only rarely.