That is the functional model in its entirety. Physical specimen-bits ARE
containers, and they can be put into other containers, which are
arbitrary curatorial declarations hopefully arranged in some useful
fashion, such as bones in boxes on shelves. Barcodes (“machine-readable
code” – 2D codes, RFID, etc.) are just machine-readable proxies to
container_id. Labels are (less reliable) human-readable proxies to
container_id.

Dimensions, container_type, procedures to disallow
infinite recursion, etc. – everything else about the model – are
attempts to prevent human errors or provide useful information about or
from containers. (All such clues are probably unnecessary in a perfect
and uniform system, but with the great diversity present in Arctos a
remark indicating the color of a box or location of a room is
occasionally valuable.)

The Model

Collection Objects are physically located in
containers, and the concept of Containers reflects that reality. Not
only are collection objects located in containers, but containers are
(optionally) located within larger containers and this relationship is
reflected in a recursive, parent-child relationship. Thus, every
container has one parent container, except for “Container Zero” (the
Parentless Void). For example, a tissue sample is typically in a
cryovial, within a position in a freezer box, within a
position in a freezer rack, within a freezer in a
room… seven containers.

With each container uniquely labeled with a barcode, tracking objects is
done by scanning a new parent-container ID into the record of a child
container. In the example above, the approximately 1,300 samples in a
freezer rack can be tracked from one freezer to another by the scanning
barcode on the freezer rack and its new parent ID (the barcode on the
freezer).

Container Type

Container . Container_Type VARCHAR(20) not null

Vials, jars, boxes, shelves, and rooms are all Container Types.
Vocabulary
is controlled, and should be limited to unambiguous and mutually
exclusive kinds of containers.

The Container Type “Position” is locked by programmed logic within its
Parent Container. Examples of Positions include entities which cannot be
physically moved from their Parent Container such as slots within
freezer racks, slots for vials within freezer boxes, and positions for
racks within freezers. In order create a Position, a Parent Container
must be assigned.

The various “label” container types are for processing. “Labels” may
generally not have parents or be children, and should be changed to some
other container type for usage. For example, one might purchase 100,000
“cryovial label” tags intended for the next several years use, and
change them to “cryovial” 1,000 at a time. A color-coding system is
useful.

Parent Container

Container . Parent_Container_ID NUMBER(22) not null

This is the value that identifies the container into which another
(child) Container has been placed. The value is not displayed in
applications because Parent Containers are generally displayed by their
Labels and entered into forms by their Barcode.

Barcode

Container . Barcode VARCHAR(50) null

Within the database, a barcode is a string of characters
unique to a container. Most barcode values are meaningless “dumb
numbers” that serve simply to associate a physical container with the
information about the container.

On labels, these characters are typically represented in one of several
possible machine-readable fonts. Code Three of Nine (usually called Code
39), Code 128, and the two-dimensional DataMatrix codes are being used
at this time. Most modern one-dimensional scanners will automatically
recognize most one-dimensional codes, and most two-dimensional scanners
will recognize both one-dimensional and two-dimensional codes. RFID,
NFC, or any other method by which a machine may interrogate a tag, are
also acceptable “fonts.”

Many barcode labels are preprinted, purchased in lots, and made in
particular sizes with particular adhesives, etc., for fairly specific
applications. Others are printed in-house. Code 39 labels can be
generated by installing a barcode font on a computer and printing to a
laser printer. Code 39 can be
downloaded for free.
Asterisks are the stop and start codons for Code 39, so an expression
such as *1234* will be read as 1234 by a barcode scanner.

In order to assure that barcode values are unique, barcodes are entered
into the database as containers of the type label. This is done at the
time labels are ordered so that the range of values is reserved. This
practice also allows us to limit the values accepted by the database to
known barcode values.

Label

Container . Label VARCHAR(255) not null

Label is the descriptive value that is displayed in most of our
object-tracking applications. It should usually represent something that
appears on the container. In many cases, this will be the value of the
barcode which is displayed in human-readable fonts on most barcode
labels.

Many legacy containers are not easily barcoded, especially if they are
numerous and stored at low temperatures. Therefore, Label should
certainly be the value that appears in physical searches for un-barcoded
containers. Note that Label is NOT unique.

Some object-tracking applications simplify the container hierarchy by
reporting only the positions (Containers of the type Position) for a
Collection Object. Thus, in order to find a tissue sample in the
freezers, you do not need to know the label of the freezer box or the
freezer rack. You need know only the positions of the box and rack. For
these applications, the Labels of positions might usefully indicate the
parent container of the position. For example, the Label of position 6-B
in Freezer 6 is “Frzr6 6-B,” not just “6-B.”

Description

Container . Description VARCHAR(255) null

Description is a useful expansion of Label. “Room 363” is useful as
a label, but something like “the processing room in the south wing of
the Biology Annex” may be expeditious.

Install Date

Container_History . Install_Date DATE(7) not null

Install Date is the date on which the Parent Container was last
changed, i.e., the date on which the Container was placed in its
parent.

Remarks

Container . Container_Remarks VARCHAR(255) null

This is the place to record notes and about the container or its contents.
Remarks are especially useful in explaining the nature and treatment of
legacy containers (i.e., containers without barcode labels).

Print Flag

Container . Print_Fg NUMBER(22) null

Print Flag is a temporary flag that can be set for the purpose of
printing container labels.

Width, Height, and Length

Container . width NUMBER(22) null

Container . height NUMBER(22) null

Container . length NUMBER(22) null

These are the dimensions of a container in centimeters.
Decimal fractions can be used. Because movement of objects involves two
barcode scans that relate a child container to a parent container, there
is a risk of accidentally reversing these two values. These dimensions
are used in logic that prevents scanning a container into a parent that
is smaller than itself.

Some common container dimensions:

Container

Width

Height

Length

13-slot freezer rack

14

73

14

slot in freezer rack

13.5

5.5

13.5

regular (2 inch) freezer box

13

5

13

2-dram shell vial

2

5.6

2

Number of Positions

Container . Number_Positions NUMBER(22) null

Some containers have immovable subcontainers of
the Container Type Position. For example, many freezer boxes designed to
contain cryovials have either 81 (9 X 9 rows) or 100 (10 X 10 rows)
subdivisions, or fixed positions, for cryovials. Recording the number of
positions in a container allows us to make forms specific to tasks such
as scanning cryovials into a 100-position freezer box versus an
81-position freezer box.

Institution

Container . Institution_Acronym VARCHAR2(20) not null

Institution is an abbreviation that indicates which institution’s
“owns” a container. (“Owns” because containers are in fact shared across
VPD boundaries; this is closer to an indication of creator.)

Display Format

Containers are displayed as a string for various purposes in Arctos, and sometimes these strings are concatenated to represent a container hierarchy as a string. The standard format is

[ barcode ] label (container_type)

Note that barcode is a NULLable field. A container with a barcode (which is the same as label in this case) will appear as

[ DGR16202 ] DGR16202 (freezer rack)

while a container without a barcode will appear as

[ ] 8 (position)

When multiple flattened containers are concatenated, colons are used for separators.

Object Tracking in General

This section describes very general guidelines for object tracking with
machine-readable labels.

Getting started

Claim a barcode series in the Barcode Series
Spreadsheet (Arctos: ObjectTracking tab).

Purchase or print labels.

Create the corresponding containers as some type of “label”
container in Arctos using the Create Container Series app.

Using

Change some labels to an appropriate usable container type (one not
containing “label”) with the Label>Container app. Mark them
appropriately; see Field Procedures for one idea.

If the barcodes are meant to directly hold specimen parts (e.g.,
if they are nunc tubes or tags), install the part into the container
using the data entry form, by editing the specimen part, with the
Parts>>Container batch tool, or any other method.

Use the container by scanning it into other containers or by
scanning other containers into it using one of the many appropriate
Arctos forms.

Object Tracking in the Field

The best place to begin the process of object tracking is when a part is
created; for example, when a tissue sample is put into a Nunc tube in
the field. Here is a brief overview of one implementation of that
process…

As part of system development

Acquire a sufficient number of 2-piece barcodes. These are generally
clear plastic labels with two identical, separable barcodes, one of
which includes a long transparent “wrap around” portion through
which the tube may be viewed, and which after application serves to
protect the barcode and any writing on the tube to which it
is affixed.

Using the Arctos tools, enter the labels into Arctos as containers
of type “{appropriate modifier} label.” Special handling exists for
“cryovial label” containers, but this is unused if these practices
are followed. “Cryovial labels” are often used on glass vials, and
being overly-specific in creating “label” container types can
ultimately result in confusion.

Acquire a sufficient number of appropriate containers.

Develop a system of color-coding commonly-used container types. For
example, agree that all “cryovial” labels will be green, and all
“vial” labels red.

Before collecting

Pull out some containers and a corresponding number of labels.

Use the Arctos tools to change the labels to an appropriate
container type – from “specimen label” to “vial,” for example.

Color-code the barcodes. Indelible ink (Sharpie markers work well)
on the peel-off backing is perhaps best, but colored rubber bands,
sticky-notes, or anything else that allows a user to identify the
intended use of the barcodes is acceptable.

In the field

Using the color coding system, grab an appropriate 2-piece label,
remove the backing and affix the appropriate half to a container and
the corresponding half to the data sheet. (Data sheets including
pre-printed common part names, the part name encoded as barcodes,
and a clearly-marked area for affixing the appropriate label-half
are useful.)

Back in the collection

Install the barcoded container by scanning it into an appropriate
box, position, etc.

Note that the two steps above are independent and may occur in any order
and at any time. Typically tubes are installed immediately upon
returning from the field, and specimen data entry may occur months or
even years later. Once both steps have been completed, the specimen,
part, and object tracking data will automatically consolidate.

At any time

If, for whatever reason, an un-barcoded container (with contents
or not) should appear in the collection, simply refer to the
color-coding chart, locate an appropriate label, and affix it to
the container. (If the container does contain something, scan that
into the new label as well.) No database inputs or container changes
are necessary to bring the “new” container into the object
tracking system. This immediately allows the container to be tracked
by scanning it into any other container, and allows it to contain
any container or specimen part.

Object tracking without barcodes

We are occasionally asked about object tracking without barcodes. While
such interfaces could be developed, we suggest that they should not be;
non-machine-based “object tracking” is best accomplished through
specimen part attributes.

With barcodes, explicitly-defined things (specimen parts) are uniquely,
unambiguously, and globally identified, then “read” by a device which is
mathematically prevented from making read errors. We maintain that this
is fundamentally different than anything produced by people reading
labels. If the machine says ContainerA is in ContainerB, there are
limited possibilities:

It really is

A protocol is ineffective

Employees are not following protocol (which probably means a
protocol is ineffective)

Without barcodes, things (often poorly-defined parts of cataloged items)
are identified by something that may or may not really be unique
(catalog number as transcribed by some student, some taxonomic term as
accepted whenever the shelf was labeled, one of the 3 objects labeled
“Catalog Number One,” etc.), and that value is interpreted by a “device”
which tends to make the occasional mistake when dealing with large
numbers of similar things. Things end up about where they should,
usually, (the aforementioned device is very good at dealing with a bit
of slop) but there’s not really any way of knowing when they don’t.

The systems are functionally different, and the data they produce are
functionally different. Most every “numbering system” created by humans
has duplicates, etc., and every human who’s ever read very many numbers
has mangled a few of them. (Statistics suggest about 4%; our experience
barcoding legacy object tracking systems suggests something higher.)
Humans can often deal with those errors, but doing so requires a very
different approach than barcodes. Machine codes are as reliable as
they’re made to be, but they must be part of a designed system; there is
and can be no room for interpretation or ambiguity.

If data of a quantifiable quality are desirable, machine-readable codes
and a system of handling them is necessary. If data of those
characteristics are not necessary, or the resources to barcode are not
currently available, use part attribute “location.”

FAQ

Summary: People who use barcodes tend to find them indispensable; they
make producing much better data much simpler.

Q: The only benefit of barcoding is that it provides you with an east
[sic] mechanism for processing large loans, doing inventories or
otherwise creating batches of specimens.
(source)

A: This is an argument that we will soon lose all photodetector, laser,
and optical devices that may be attached to small computers. Other types
of “barcodes” (2D codes and RFIDs, for example) require slightly more
advanced technology, but the argument that very simple methods of
reading very simple encoded data across very short distances will
suddenly become impossible just does not make any sense to us.

A: Barcode physical objects – things you loan, need to find in the
collection, or otherwise track. Cataloged items (things to which catalog
numbers are assigned) are almost never appropriate; insect genitalia are
separated and stored away from the pinned “voucher,” a mammal may have
multiple organ samples, a plant may be mounted on multiple sheets, etc.
That is, barcode and GUID are different types of identifiers used to
represent entirely different types of objects. Please note that this is
contrary to the iDigBio Specimen Barcode and Labeling
Guide
(archive),
which states “A digital specimen GUID is what identifies the specimen
(part of an individual, an individual, a set of individuals) in the
digital world, while a barcode label identifies the specimen in the
physical world. “ A GUID/catalog number is assigned to whatever a
curator chooses (and traditions vary widely across disciplines and
collections), while a barcode is assigned to definable physical objects.
A barcode may refer to a cataloged item, part of a cataloged item, a
part cataloged in multiple collections, material referencing a cataloged
item or parts thereof (../images, field notes, acquisition records), or
anything else; any 1:1 catalog number:barcode ratio is coincidental and
likely indicative of data structure problems.

A: Nothing. All of the above (and much more) is tracked in Arctos under
one system. A system which must be modified for “special” situations is
almost certainly also lacking in “normal” usage.

Q: What “numbers” should I use?

A: Anything unique within your “globe” is sufficient; the larger the
“globe,” the more you one can do with the data. Arctos currently has a
system-wide unique key on barcodes, which allows us to deploy
Arctos-wide tools which are used to track objects loaned to other Arctos
collections, create loans (including those which include material from
multiple collections) by scanning barcodes, transfer barcoded (and
tracked) objects across collections, and store material from various
collections in the same parent containers (e.g., freezers). We find no
fault in the iDigBio Specimen Barcode and Labeling
Guide
(archive)
recommendation of using UUIDs for barcodes, although most collections in
Arctos prefer a human-readable label prefix. DOIs which resolve to the
part internally and specimen externally seem ideal (they’re
globally-unique and resolvable if inadvertently cited), though we have
so far been unable to procure sufficient DOIs to test this idea at
scale.

Q: What encoding should I use?

A: Whatever fits on your desired labels and can be reliably read by a
convenient machine.

Usage

This section provides a brief overview of the Arctos container forms and
applications. It is not all-inclusive and it should not be viewed as
directive.

Find a container

Containers may be located and displayed hierarchically through Find
Container, which is accessible directly through the “tools” control in
Specimen Results, from Specimen Detail, from loans, and various other
places within Arctos. Please note that the container “tree” form is
dynamic and asynchronous – clicking controls repeatedly (esp. from slow
connections or searches that return large results sets) may “clog up the
pipe” to the database; be patient.

Once a container search has successfully completed, you will be
presented with a “tree.” Doubleclicking any node will expand that node
to show all its child containers. Clicking the checkbox beside a node
will open a “more information” window, the contents of which are
context-dependent.

“Edit Container” provides the ability to edit the container, move it
to a new parent, add a “checked” entry, record fluid information,
and provides a list of the children of the container.

“See all collection objects” will return a list of parts as “leaf
nodes.” This includes parts that are in the container, and parts
that are in containers that are in the container at any level
of recursion.

“Positions” is functional only for appropriate container types. Note
that nothing prevents adding additional material to a container
which contains positions, but that doing so will disable the
position form.

“History” provides a scan history, and may be useful for locating a
misplaced container.

Use Containers to add items to a loan

Use the “Bulkload Loan Items” batch tool or the “add items by barcode”
link from Edit Loan.

“Flattening”

There are various options to “flatten” a container hierarchy into a map
for locating specimen parts, generally used in conjunction with loans.
These are part (not specimen) based, and so the option from specimen
results will flatten all parts for all specimens included in the results
set, while the options from loans will flatten only those parts which
are included in the loan. Note also that loans often contain subsamples,
which are generally not included in object tracking systems.

General System Guidelines

The following are general guidelines developed largely from examining
error logs (or a lack thereof) in relation to the number of tracked
objects, the apparent ability to find supposedly-tracked objects, and a
general impression of overall “quality” and utility of the barcoding
system in several collections. This is not a recipe, but rather a
description of the general qualities of the finished product.

A system is critical. Scattering some barcodes around and
occasionally beeping at them with a scanner does not somehow lead to
knowing where things are.

Containers should be created (as container type “% label” - currently “container label”, “cryovial label”, and “specimen label”)
in large batches, when
printed or purchased.

Containers should be edited exactly one time, when containers of type “% label” are
changed to containers of usable types for immediate usage. (See field
procedures.)

All other container-related tasks involve only scanning barcodes.

Creating position-holding freezer boxes (From MLC 2016-01-19)

create a freezer box in object tracking ( or use bulk container edit
to create a bunch)

I prefer, even with 9×9 grids, to create the box wit h100 positions.
That way, each row will be 1-10, but you don’t fill the
10th position. This makes the numbering easier.

So, make sure that for “number of positions”, you put 100 (or 81 if
you prefer, but once you create the positions, they can’t
be changed).

then go find the container using object tracking

click on the container, putting the check in the box next to it so
that that the”edit container” screen shows up to the right

below edit container and see all collection objects in this
container, you will see a “positions” tab – click on it

say yes to create new positions

it should generate a form with a freezer box template that you can
scan tubes into

note that if you scan a tube in place, and then need to move it, you
must scan it into a different position first, and then refresh your
browser to delete it from the old position

Barcode Series

Before being used in Arctos, barcodes must be “claimed” (“Barcode Series” under the Object Tracking tab).
Claims should strive to include everything that will ever be used from a “series” and nothing that should
not be in Arctos. This pre-claim prevents the creation of unintended barcodes, clarifies why a barcode exists
(e.g., when encountered by another collection, perhaps while on loan), and provides a check for unintended data
(e.g., when someone scans something that probably should not have been scanned, or types rather than scanning).

While anything that Oracle can process will be accepted, the easiest way to define a “series” is often through
regular expressions. Oracle’s regexp_like function accepts fairly standard regex; a search engine will likely find a situation
similar to what you’re trying to accomplish.

Example

Desired series:

UTEPROOM100-UTEPROOM299

SQL to claim:

regexp_like(barcode,'^UTEPROOM[0-9]{3}$') and to_number(substr(barcode,9)) between 1 and 299

Explanation:

regexp_like

Use regular expressions in SQL

barcode

the thing against which the regex will run

^

“starts with”

UTEPROOM

just a string - anything that’s not “UTEPROOM” won’t make it through

[0-9]

then some number-character

{3}

three of them

“{1,3}” is “1,2,or three occurrences” “{,3}” would include zero in that, “{3,4}” is “three or four of the preceding” etc.

$

nothing follows

That establishes the pattern, but we also wish to exclude UTEPROOM099 and UTEPROOM300; we need to define the numerical part of the series.
To do so, we add the “and” portion, which is processed only after the regular expression has been successful

and to_number(substr(barcode,9))

substr(barcode,9)

From the 9th character of the barcode to the end…

(substr(barcode,9,3) would be “three characters after the 9th character”

to_number

convert datatype

between 1 and 299

and check that the number we’ve extracted is between a range (identical to (>=0 AND <=299) )

Guidelines for barcode-containing labels

Barcodes should be clearly replicated in a human-readable format.
The value read by a scanner should be readable by a human as well.
Note that XYZ123, 123, ZYX 123, zyx0123, and ZYX0123 are all very
different values.

Be cautious of lower-case letters. Many barcode readers transmit all
data in upper-case. Arctos character comparisons are bitwise; a and
A are not the same character.

Avoid padding with leading zeroes. These may be handled differently
by different applications. In order to keep the character strings
all the same length, start the series at a high value. For example,
instead of beginning a series at 000001, begin at 100001. Thus, the
character string will always be six characters long, and the printed
labels will format consistently.

Avoid characters other than A-Z and 0-9. Humans, and sometimes
machines, can’t always tell if that hole represents a space, tab,
linefeed, of any of the dozens of other possibilities. Barcodes
containing anything except A-Z, a-z, and 0-9 are NOT eligible for
any script-processing through Arctos or TACC, except by
previous arrangement.

Use big numbers if possible. XYZ1234567890 is less likely to cause
unanticipated problems than XYZ1 is.

Don’t try to be too clever. You’ll learn to hate “L090207” (or was
it L927? Maybe L0902007?). Dumb numbers with a locally-meaningful
prefix, such as UAM or UAMMAMM, will be much more sustainable.

Check the Barcode Series Spreadsheet (Arctos: ObjectTracking tab)
very early in the ordering process. Avoid anything that even
remotely looks like it could be, or ever could become, a conflict.
Duplicate barcodes will not be accepted. Barcodes are shared across
all Arctos collections.

Talk to the Arctos folks before doing anything else. Really. It’s
free, and we’re here to help. Ordering unusable barcodes is not
free.

Enter the series of barcodes into Arctos and update the Barcode
Series Spreadsheet (Arctos: ObjectTracking tab) before placing an
order or printing your barcodes.