Duplicate Tags
From PTAGISWiki
Contents |
Definition of a Duplicate Tag event
If a tag data file contains a tagging/release record for a PIT tag that has been previously reported as a new tagging event in another data file, then the second occurrence of that tag is identified by PTAGIS as a Duplicate Tag. The Duplicate Tag event is stored to the tag_dup_data table in the PTAGIS database, separate from the original tagging event stored in the tag_data table. The Duplicate Tag event is hidden from reports that correlate the tagging event data with subsequent recapture, automated detection (interrogation), and mortality events.
Causes of Duplicate Tag events
There are four types of activity that cause Duplicate Tag events. In descending order of prevalence (with #1 being the most common), a Duplicate Tag event occurs when:
- A tagged fish is recaptured, but is reported in a tag data file without an "RE" recapture flag in the Conditional Comments field.
- A researcher re-uses a tag retrieved from a dead fish without first removing the reference to the original tagging event.
- A researcher mis-identifies a PIT tag code as s/he manually records that tag code.
- A second PIT tag is inadvertently inserted into a previously-tagged fish and the original tag code is recorded; see Double-tagged fish.
Prevention of Duplicate Tag events
The preferred solution to resolving Duplicate Tag events is to prevent them from occurring in the first place. Techniques for preventing the occurrence of Duplicate Tag events include:
- Pre-scanning all fish for PIT tags in situations where previously-tagged fish may be encountered. This is a critical action that is required of all researchers PIT-tagging fish, to ensure that they do not compromise their own or other researchers' mark & release projects;
- Manually or mechanically diverting previously-tagged fish away from marking stations;
- Using the Tag Action function in the P3 data entry software to alert you to the presence of unexpected tag codes; and
- Employing project management techniques that synchronize the re-use of PIT tags with the excision of the prior tagging data from tagging sessions and tag data files.
Correction of Duplicate Tag events
There are two general methods of correcting Duplicate Tag events in the PTAGIS database. The type of correction method employed depends on the cause of the Duplicate Tag event.
If a tag's original tag/release record is correct, but a subsequent record for that tag should have been, but was not, flagged as a recapture, the solution is to simply update the P3 tag record for that recapture to include an "RE" flag in the Conditional Comments field, save the updated tag session, and reload the corrected tag data file to PTAGIS. This is the simplest solution and, fortunately, is also the most common type of Duplicate Tag event.
If the reported record for the Duplicate Tag event is in fact the "true" mark/release event, then the existing "false" event in the PTAGIS tag_data table is blocking the true event and must be excised. This requires first correcting the tag data session containing the "false" event record to 1) remove the "false" record, 2) dot-out the tag code in the "false" record, or 3) flag as a Recapture (or a Mortality) the "false" record. Next, the corrected tag file for the tag data session containing the "false" event must be re-loaded to the PTAGIS database, in order to remove the "false" tag code from the PTAGIS tag_data table and "unblock" the Duplicate Tag code. Finally, the data file containing the "true" mark/release event must be re-loaded to the PTAGIS database (also as a "corrrection") in order to properly instantiate the "true" mark/release event in the PTAGIS tag_data table.
