Editgroupeditgroup_rrxqtibgqzfk7chzcifixu63x4

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.

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.

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.

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

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.