In some situations, tags are deployed in a way that only a small
number of receivers, known in advance, could detect them, at least for
a known period.
Examples:
calibration experiments on tags in a lab, with several receivers
used for replication
deployment on organisms with no/low mobility in remote locations
with a small number of receivers installed nearby to monitor them
In such situations, we'd still like the automated data processing
system to work and return useful results for people, but there are some
issues to keep in mind:
isolated tags should not be sought in data from receivers other
than those in the isolated area.
isolated receivers might still detect mobile tags from other projects,
depending on how receivers are set up.
Benefits
If we process data from such situations in the usual way, but with a
metadata indication of "isolation", we gain:
no special-purpose code to maintain and run for these datasets; the usual
motus-based system will still be used
the isolated tags won't compete for pulses in datasets from sites
where they could not have been detected; this could lower the false
negative rate on other tags
no bogus detections of identical non-isolated tags by isolated receivers,
thus lowering the false positive rate on the former.
Implementation
We need these concepts:
isolated tag deployment a tag deployment where the set of receivers
which can detect the tag is limited and known in advance
isolated tag set a set of isolated tag deployments detectable by the
same set of receivers
isolated receiver deployment a receiver deployment which is able
to detect tags in an isolated tag set. The receiver might also be
able to detect non-isolated tags.
And these semantics:
a tag deployment is marked as isolated by assigning it to an isolated
tag set. The isolated tag set is an integer ID field added to the tag
deployment record, and linking to an isolatedTagSets table with these
fields:
CREATE TABLE isolatedTagSets (
ID INTEGER UNIQUE PRIMARY KEY -- unique ID for this tag deployment
label TEXT(32), -- short label for tag
projectID INTEGER references projects -- motus project ID
)
a receiver deployment is marked as isolated by associating it with
an isolated tag set.
an isolated receiver deployment can be:
exclusive: the receiver can detect only tags in its associated
isolated tag set
inclusive: the receiver can detect all non-isolated tags as well
as tags from its associated isolated tag set
So the receiver deployment would need two additional fields:
isolatedTagSetID INTEGER references isolatedTagSets(ID), -- unique ID of isolated tag set with which
-- receiver is associated, or null for a
-- non-isolated deployment
exclusive INTEGER(1), -- 0 means this receiver can detect all
-- non-isolated tags as well; 1 means this
-- receiver can detect only tags from its
-- isolated tag set; ignored if isolatedTagSetID
-- is null
When data from a receiver deployment are run through the tag finder,
the set of tags sought is:
non-isolated receiver deployment: all non-isolated tags
This is the current and most common case; corresponds to a default (NULL)
value for the isolatedTagSetID field in the receiver deployment record
exclusive isolated receiver deployment: all tags from the associated isolated tag set
inclusive isolated receiver deployment: all non-isolated tags, plus all tags from the associated isolated tag set
So the usual case wouldn't require any additional action on the part of users.
The isolated tag and receiver deployments would require that the user choose
an isolation set (for tag and receiver deployments) and exclusivity state (for receiver deployments).
In some situations, tags are deployed in a way that only a small number of receivers, known in advance, could detect them, at least for a known period.
Examples:
calibration experiments on tags in a lab, with several receivers used for replication
deployment on organisms with no/low mobility in remote locations with a small number of receivers installed nearby to monitor them
In such situations, we'd still like the automated data processing system to work and return useful results for people, but there are some issues to keep in mind:
isolated tags should not be sought in data from receivers other than those in the isolated area.
isolated receivers might still detect mobile tags from other projects, depending on how receivers are set up.
Benefits
If we process data from such situations in the usual way, but with a metadata indication of "isolation", we gain:
no special-purpose code to maintain and run for these datasets; the usual motus-based system will still be used
the isolated tags won't compete for pulses in datasets from sites where they could not have been detected; this could lower the false negative rate on other tags
no bogus detections of identical non-isolated tags by isolated receivers, thus lowering the false positive rate on the former.
Implementation
We need these concepts:
isolated tag deployment a tag deployment where the set of receivers which can detect the tag is limited and known in advance
isolated tag set a set of isolated tag deployments detectable by the same set of receivers
isolated receiver deployment a receiver deployment which is able to detect tags in an isolated tag set. The receiver might also be able to detect non-isolated tags.
And these semantics:
a tag deployment is marked as isolated by assigning it to an isolated tag set. The isolated tag set is an integer ID field added to the tag deployment record, and linking to an isolatedTagSets table with these fields:
a receiver deployment is marked as isolated by associating it with an isolated tag set.
an isolated receiver deployment can be:
So the receiver deployment would need two additional fields:
When data from a receiver deployment are run through the tag finder, the set of tags sought is:
So the usual case wouldn't require any additional action on the part of users. The isolated tag and receiver deployments would require that the user choose an isolation set (for tag and receiver deployments) and exclusivity state (for receiver deployments).