The tag detector should output deployment IDs, not tag IDs, and ambiguities
should be managed among tag deployments, not tags.
Rationale
the list of tags being sought is time-dependent, based on deployment dates, so
it really is a tag deployment that is detected
ambiguity isn't among tags per se, it's among tag deployments, since identical tags
are not ambiguous if their deployments do not overlap
Benefit
This will simplify queries for ambiguous detections from the master
database. Here's how we have to look up ambiguous detections that
might belong to project P:
search the tag ambiguity table for records containing a tag that was
deployed at least once by P, and record the (negative) tagAmbigID
for each tagAmbigID, search for runs on that ID, and then link appropriate
hits and batches.
to be strictly correct, we should then filter runs so that only those which
match a deployment of tag X by project P remain. (i.e. if a different project
Q redeployed the same physical tag, we don't want users of P to obtain
ambiguous detections that could only be the deployment by Q, not the one
by P).
This is the step which would be avoided by having ambiguity management
operate on tag deployments, rather than tags.
Note that the tag finder only assigns (negative) ambiguity IDs to detections that
actually are ambiguous based on deployment dates and lifespans, but these are
recorded as representing one of up to 6 possible ambiguous motusTagIDs, rather
than deployIDs. This is why we need to go through the last step.
The tag detector should output deployment IDs, not tag IDs, and ambiguities should be managed among tag deployments, not tags.
Rationale
the list of tags being sought is time-dependent, based on deployment dates, so it really is a tag deployment that is detected
ambiguity isn't among tags per se, it's among tag deployments, since identical tags are not ambiguous if their deployments do not overlap
Benefit
This will simplify queries for ambiguous detections from the master database. Here's how we have to look up ambiguous detections that might belong to project P:
search the tag ambiguity table for records containing a tag that was deployed at least once by P, and record the (negative) tagAmbigID
for each tagAmbigID, search for runs on that ID, and then link appropriate hits and batches.
to be strictly correct, we should then filter runs so that only those which match a deployment of tag X by project P remain. (i.e. if a different project Q redeployed the same physical tag, we don't want users of P to obtain ambiguous detections that could only be the deployment by Q, not the one by P). This is the step which would be avoided by having ambiguity management operate on tag deployments, rather than tags.
Note that the tag finder only assigns (negative) ambiguity IDs to detections that actually are ambiguous based on deployment dates and lifespans, but these are recorded as representing one of up to 6 possible ambiguous motusTagIDs, rather than deployIDs. This is why we need to go through the last step.