Reconciling Depositor name change with subsequent dataset updates

[zoidy]

When a depositor changes their name on their profile and subsequently updates an existing dataset, LD-Cool-P recognizes that the dataset is v2 and creates the appropriate folder structure. However, because the v1 dataset was named using the previous depositor name, you will now have two folders, one with v1 and one with v2

Old_Name_12345678
-v1

New_Name_12345678
-v2

I'm not sure what the best way to reconcile this situation is. Two solutions that come to mind

1. Have the software always ignore the name and only consider the article_id when looking for the correct folder.
2. Strip the depositor name from all folders (not ideal for human readability)
3. EDIT: another option is to rename Old_Name to New_Name
4. EDIT: another option is to not address this edge case and manually correct the problem.

[astrochun]

This is a good point that you raise. Question: What does the citation metadata show for v1?

Option 1 would work but keep in mind that the DepositorName class uses the newest figshare metadata. It would require re-working that piece of metadata code to handle such an exception. DepositorName has significantly evolved as more metadata have been incorporated into it. I've been wanting to refactor it to make it easier and to have metadata modular depending on sources/needs. Note that a unique identifier ID does exist for each depositor. The trouble is keeping track as Figshare does not keep track of previous names. Honestly, what happens if someone keeps changing their name because they can't decide?

Option 2 is not UX, so that's out. I made a choice to do it as such simply for human readability.

Option 3 might work. One thing I wonder is what would happen if say we attempted to retrieve the data. If it uses the new name then I think we are OK. Though this seems very similar to Option 4 as renaming can easily be a manual correction. Though keep in mind, do we want to keep a record of such a change? Note that other stuff (e.g., curation review report) has such information.

Keep in mind that a simple symbolic link for v1 to the new folder might just work after publication.

[zoidy]

Option 3 might be the simplest right now. Especially as we begin to ramp up preservation work, it might be easier both from the software side and human side to refer to things using their current name. A record of the change would already be present in the readme and/or curation reports. Because of that, I can't think of a reason to keep track of such changes separately, especially since other things like title can already be mismatched between the review report and the actual title.

EDIT: the difference between option 3 and 4 was that 3 was some sort of auto detection and renaming. I don't know enough about the code to know the implications of doing that though