It’s been a personal obsession to merge newer duplicates into pre‐existing entities rather than the opposite.
Even if the target data has to be fixed at the same time (better title style or missing artist credits).
I had made a user script to ease spotting the oldest created MBID (mb. MERGE HELPOR 2) and a wiki page to list the known inconvenients of merging old entities into newer ones.
But maybe the inconvenience is mostly theoritical to me as I don’t use flickr machine tags any more and as mb. COLLECTION HIGHLIGHTER is just a user script.
The MERGE HELPOR also has other useful features for merge editors (mostly on the merge page itself), such as:
Highlights last clicked entity
Shows additional info for each about to be merged entities — An old example for works: https://imgur.com/5AlDF — each entity types has its set of added info, like amount of recordings, works, etc. for artists
Indicates oldest MBID
“Remove entity from merge” buttons
“Clear queue and add to merge” button — doesn’t reload page for nothing when nothing is checked (currently broken feature, apparently)
Other than the age of the MBID, does it make a difference which direction the merge goes? If I merge a newer (but more complete) entry into an older but sparser one, will anything be lost? (If not, why doesn’t MB just pick for us based on the oldest MBID?)
I’m generally happy with a merge either way when the entities are equally good. But otherwise, if one has a better name, or artist credit (for a recording or release) or the like, I’d always merge into the most correct, whatever is the oldest. Otherwise, the resulting entity needs to be improved again.
Except a few images I had uploaded, I don’t really use flickr MB machine tags.
But it’s an example of what is broken by targeting the duplicate instead of the pre existing MBID.
I do use COLLECTION HIGHLIGHTER, which is also broken by this.
If I find other problems, I will add them to that wiki page.
Yes, at least to some degree. If I merge “Symphony no. 1 in D major, op. X: I. Adagio” by “Orchestra X, Conductor Y” into “Adagio” by “Composer”, that’s IMO destructive. Sure, it can be reconstructed from a tracklist and a script, but it has made the data worse in the meantime
Yes, if you wrongly merge you cannot tell this AcoustID was for this track and that AcoustID was for that other track.
Same for ISRC, unless the Add ISRCs edits were will referenced (which is rare because ISRC web service does not allow edit notes, you have to come back to edit history to ad them manually).
Same for relationships, etc.
Splitting unmerging recordings is difficult and you will have to wipe out at least the AcoustIDs.