Table of Contents
Merge two entity records
More recent versions of RIMMF include support for merging two entity records into one. This might be useful when combining data folders from different people working on the same project (as in a jane-athon, for instance).
To use the record merge utility, go to your Entity Index and identify the records you want to merge. Typically, filtering on an entity and sorting the list of composite keys is the best way to go about this. Once you found the records you want to merge, select each one (select one, hold CTRL Key, select the other):
IMPORTANT The merge utility requires that exactly two records of the same entity be selected. If you select three, the utility will not get invoked. If you select two records of different entities, the utility will not get invoked.
After you have selected the two entity records that you want to merge, right-click on either one of them. This action will invoke the merge utility (there is at present no menu option that will do this).
Using the merge utility
The RIMMF Merge Utility will open in a new window and display two panels side by side, with each panel containing one of the selected records. The AAP for the record, followed by the shorturi, will appear at the top of each panel, followed by the elements in the record:
The Control panel for enacting the merge appears beneath the record display. The available actions are very simple.
First, you can highlight the fields that are the same in each record, or the fields that are different, or none at all (do not highlight anything–the default). Highlighting the differences may make it easier to determine which record to keep and which to delete.
Once you have determined which record to keep, the next step is to … initiate the merge.
There are two 'Merge To' buttons, one beneath each entity record.
- The button on the left merges the record on the right into the record on the left
- The button on the right merges the record on the left into the record on the right
When you press one of the merge buttons, a colored caption appears beneath each record, describing what will happen to that record after the merge completes:
- The record to be kept is identified by a green caption
- The record to be deleted is identified by a red caption
Here's another screenshot of the control panel for the example above, with difference highlighting turned on:
To run the merge you must then press the same button a second time. This gives you a chance to change your mind–just press the button pointing in the other direction to reverse the direction of the merge–or to exit entirely (by closing the merge utility window).
If you go ahead–in this case, we'd press the button on the left a second time–the program will run the merge and show you the results. All of the fields present in the merge-from record that were not present in the merge-to record are added to the merge-to record, and highlighted (green) in the utility display.
But even at this stage, the physical merge has not occurred. The program has merged the records in memory only. You can still back out by pressing the large Cancel the Merge button. Or complete the process by pressing the equally large Finalize the Merge button:
So, we now press the Finalize button.
At this point, after you say <OK> to dismiss the usual 'Are you sure' warning about deleting a record, the merge occurs, and the merge-to record is displayed in the typical RIMMF manner.
Notes about merging
The above describes how to merge two records, but it does not describe how to decide what record to keep or what record to delete, or even what a duplicate record is. Its likely that in 'triplestore cataloging' the concept of duplication–a concept we carry with us from the MARC world–will need to be radically changed, if not tossed out altogether. This topic is beyond the scope of this wiki page, and probably beyond the scope of RIMMF3.
Getting back to the mechanics of the merge, the utility simply copies the unique fields in the merge-from record to the merge-to record. By 'fields' we are referring to a string composed of element + text1). So, if one record has the field
then, for the purposes of the merge, they are considered different (even though the element used is the same in each case).
In addition, the utility makes no attempt to normalize out superficial differences2). Therefore, these two identifiers are seen as different:
LCCN n83026400 LCCN n 83026400
and will trigger a merge of one or the other. At present, there is no way to block this from happening (perhaps in a future version we might add a checkbox to each field that allows removing it from consideration).
However, one of the nice things about the merge utility is that it handles all of the links–and the inverse of each links–automatically for you. When the merge completes, merged relationships should all function the same way in the merged-to record as they did in the (now deleted) merged-from record.