How to handle duplicate records
Merging 2 puzzles into one record...
Henrik Rasmussen
Last Update 24 天前
It is a major task for IPDb to make sure that we minimize the number of duplicates found in IPDb, as it is confusing to all of us.
Our first line of defense is the duplicate filter that is running while we insert new records. At times, the potential duplicate window will pop up and suggest that a user may be about to insert a record already in IPDb.
Read this article on how to handle this situation...
Nevertheless, duplicates may still find their way into IPDb at times. This article will explain to you how to handle duplicates that have slipped through the net.
NOTE:
A word of warning to start off with. Some puzzles may SEEM to be duplicates, as they look exactly the same. However, they may be ever so slightly different and will therefore be treated as separate records instead of duplicates in IPDb.
Examples of records which ARE NOT duplicates
Puzzles from the same brand, but with
- different barcodes
This typically happens if the same puzzle is produced in different factories/countries. It may also happens if a puzzle was sold out, and a second edition was produced years later. - different boxes
Over time, brands may release versions with minutely different boxes - either front or back. It may be a font change, or slightly different elements on the cover, or they may completely overhaul the box cover for an updated look. If there is the slightest difference between boxes we consider them NOT to be duplicates. - different types of cuts
Some brands, Eurographics being one of the main ones, release the same puzzle in different regions with different cuts. Eg if manufactured in the US/Canada or China, they have varying types of grid cuts. However, in Europe, they release their Smart Cut versions, which is a random cut.
And whilst their barcodes and reference numbers may match across regional releases, the type of cut differs greatly. So in this case, the European Smart Cut version should have its own record. The box will be different as well in most cases, as the newer one will display the Smart Cut logo.
There are likely to be more instances where puzzles that appear the same, but are not, which makes the problem of duplicates even more frustrating.
Reporter: How to report a potential duplicate
1. First, navigate to PuzzleA and
PC: click the link icon at the top of the details screen.
Mobile device: tap the additional options icon, then select Copy puzzle link to clipboard
This will copy a link to PuzzleA onto the clipboard (in the background).
2. Then, navigate to PuzzleB and click the message icon at the bottom of the details screen.
This will display the Message box, which is used within the IPDb app to send messages to other users.
3. In the popup window, select the merge tab and paste the link from your clipboard onto the edit box. The paste icon is located to the right of the link field - pressing this will past the link you copied previously into the link field.
4. By pressing OK, your request to merge PuzzleA and PuzzleB into one common record will be submitted to the Admin Team, as well as submitters of both puzzles.
SubmitterA and SubmitterB will have to either accept or reject the merge request, and can let Admin know if there is a reason why the 2 records should not be merged, but remain as separate records.
The Submitters are given 28 days to respond, and if they fail to approve/deny your request, the request will be executed automatically (if Admin agrees that the records should be merged).
If a merge proceeds, the most recent puzzle is always merged into the original puzzle. So if PuzzleA was submitted last year, and PuzzleB was submitted this year, puzzle B will be merged into PuzzleA.
IPDb will check and determine which one is the original submission, so you won't have to worry about figuring that out.
This is important to know, as PuzzleA in this case has priority, meaning that if PuzzleA has artist put as Pablo Picasso, and PuzzleB has artist put as Picasso, then The merged record will have artist put as Pablo Picasso.
However, new information from PuzzleB (which doesn't exist in PuzzleA), will be merged into PuzzleA, so the merged record is a true union of the 2 puzzles.
Waiting for decisions..
Whilst waiting for SubmitterA and SubmitterB to decide if they agree that the 2 puzzles are indeed a duplication, the Reporter can follow the progress in their own Messages box.
The Merge Request info starts by stating who reported it, and when it was reported. Newest requests are listed first.
The subsequent sections detail which puzzle is to be merged into which puzzle. The names of the puzzles are underlined, as they provide a link to the actual puzzle records.
The final section lists the status of the request. Both record Submitters are listed, alongside a status of who has agreed to the merge request, and who hasn't yet to date.
Admin is also mentioned here. The IPDb Admin Team will monitor all Merge Requests, and will need to consent to the merge as well after review.
The Merge Request will stay in the Reporter's message box for 8 weeks (56 days), giving them ample time to see which requests were denied, and for what reason, and which were carried out.
In addition, the Reporter will receive messages in their normal inbox when the request status has changed and the duplication report has been resolved.
Regardless of whether or not a response has been received by the parties involved, the Merge Request will be executed or denied within 28 days.
Submitters: Somebody wants to merge your puzzle...
This section explains how the Merge Request is experienced by the Submitters, in our example SubmitterA and SubmitterB.
When a Merge Request has been created that involves a puzzle record of theirs, the Submitters or the records involved will receive a message, and a red notification number will appear on the review icon in their message box, as well as on the cog icon (settings) in the main app screen. This red number will remain for as long as the Merge Request hasn't been executed yet.
The Merge Request is mostly the same as what the Reporter can see, but with one important difference - the buttons at the bottom.
The Submitter should carefully examine and determine if they agree that either the request is valid (that the 2 puzzles are indeed duplicates), or if they disagree.
The Accept button will accept the request right away and changes the status for that Submitter as such.
If hitting the Deny button, the Submitter is asked to explain why they disagree with the request.
If any of the involved parties deny a request, the request is closed and the merge will not happen.
The request will still remain in the message area for 59 days even when denied, so if anybody feels this is the wrong decision, they should open a ticket the IPDb Help Center (via the "?" icon in the app).
The request will then be reviewed and updated.
The updated information is visible to everybody involved - all Submitters, the Reporter and the Admin Team.
So when does the merge happen?
If both Submitters and the Admin Team agree to the merge, it will happen within 24 hours after the last party has accepted the Merge Request.
If any of the Submitters or the Admin Team does not reply to the request, it will happen automatically after the 28 day wait period.
Once the puzzles have been merged
All IPDb users who have added something to the most recent record submitted (eg Smoky Trian above) will receive a message in their inbox, explaining that their information regarding this puzzle now relates to the newly merged puzzle (eg Smoky Train above), and they are encouraged to go and check that record to ensure everything is ok.
Sometimes, certain information cannot be transferred in the merge, mostly concerning information that is present in both puzzle records.
For example, if a user has made a review for both PuzzleA and PuzzleB, then only the review of the original record persists and the review of the puzzle that got merged will be lost. So it is important to check that all is ok after a puzzle you have contributed to has been merged.