barcodes, 21 July
Date: Wed, 21 Jul 1999 09:01:45 -0800 To: barcode group:;;@elwha.evergreen.edu; From: "John T. Longino" <longinoj@evergreen.edu> Subject: barcodes, 21 July In response to Steve's of 21 July: Well, Steve is forcing me to consider having the symbology contain only part of the unique identifier. I could be convinced that the advantages outweigh the costs. First I have a question for Steve: as I understand it from your message, your label looks like ||||||||||||||| SM1234567 KUNHM-ENT So what exactly is the unique identifier in the database? SM1234567KUNHM-ENT? SM1234567 KUNHM-ENT? KUNHM-ENT SM1234567? It seems to me there should be nothing else on the label except the symbology and the unique code, exactly as it should appear in a database. There should be no ambiguity about exactly which part of the human readable label is the identifier. Also for this reason I don't like spaces in unique codes. They make me nervous. Brian Brown at LACM uses spaces ("LACM ENT 123456") and I kind of wish he didn't. What are some consequences of having the symbology contain only part of the code? In a mixed collection it means the operator will not know what part of the code is contained in the symbology. In some cases it might be the whole code, in others a portion of the code. This means whenever a scanner is used for data entry, the code or list of codes will need to go into some kind of buffer where the operator can look at them and add the missing parts of the code. I use Colwell's Biota to manage both the ALAS database and my own database on ants. It is designed for the opposite situation, where the symbology contains the full code, and you want to recognize a particular prefix for various reasons. At this point it would lose a lot of functionality if it had to deal with partial codes. Partial codes might tempt people to use partial codes in their databases, with the idea that the prefix can be added later or when the data are exported. Project ALAS did this up until recently. The unique identifiers on the labels are of the form INBIOCRI001234567, and what we stored in the database was IB1234567. We decided this was a dangerous precedent, and would cause problems later. I was already having problems keeping my ant database coordinated with the ALAS database, because I used full prefixes in the ant database (where I also have LACM codes and Univ. Oklahoma codes, hence the concern about mixed codes). It was also a pain remembering to add the full prefixes when exporting the data to collaborators. The original reason for the abbreviation was to save space, but saving disk space seems increasingly irrelevant in today's world. We have just converted the ALAS database to have full codes. This will be increasingly important as databases are made accessible on the Web, and global searches for particular specimen codes will be possible. If we do accept partial symbology, what software tools will be needed? Your institution's prefix would need to be added automatically (because most of the material you handled would have your institution's prefix), unless you override it by choosing some other prefix, perhaps from a pop-up list. Steve, how do you handle this at Snow? Enough for now. Steve, thanks for adding so much to this discussion. I hope you are willing to keep it up! Jack ****************************************************** John T. Longino Lab I, The Evergreen State College Olympia WA 98505 USA longinoj@evergreen.edu Ants of Costa Rica on the Web at http://www.evergreen.edu/ants Project ALAS at http://viceroy.eeb.uconn.edu/ALAS/ALAS.html ******************************************************
Discover Life in America | Science | Unique Identifiers & Barcodes | Correspondence | John Longino - 21 July, 1999 |