|Overview of Tracy|
|Tracy was developed at the CSDL
in conjunction with the Texas
A&M Biology Department Herbarium and the S.
M. Tracy Herbarium at Texas A&M University. Tracy
was created because the increased use of the WWW, and the Internet itself,
has provided an excellent opportunity for the reduction in costs associated
with biological taxonomic research, and a great increase in the abilities
of the taxonomic researchers. It also allows us to make a great deal of
previously somewhat inaccessible information available to the public
at large. Clearly for the herbarium community to take advantage of
the digital medium requires that information about the specimens in the
herbaria be kept in some digital form. While there has been (and
continues to be) much argument over what information needs to be
(or should be) captured, it was agreed that a system such as Tracy
should be developed as a first step in this process. Tracy is the
interface to a relational database system consisting of Paradox tables
accessed via the Borland Database Engine. The BDE allows Tracy
to access the data tables directly (for speed) and via SQL (for ease of
query creation and the reporting of the corresponding results). With
the BDE Tracy can be extended to access just about any popular commercial
SQL server with a minimum of effort.
The data model used by Tracy is a subset of the Flora of Texas Consortium Data Exchange Format. The DEF reflects the data management philosophy adopted by the FTC: each member institution should be allowed to archive their data in the format that best suits them, but that each member should also be prepared to produce and accept data in a proscribed format so that information can be exchanged. This means that when a herbaria makes a request for data they can expect the data to be a subset of the DEF fields. This position was adopted due to the belief of the members that individual herbaria would not be accepting of a dictated data model and that allowing local data to be stored in a local format was the best way of encouraging the herbaria to participate in the program. This approach is in contrast to the global database model.
A global database model would generally consist of each member herbaria storing their data in a relational database of common design. This requires a large database design that all the members must agree upon a priori. Any additions or changes to the model would then have to be agreed upon again by all the members since all the members would then have to modify their databases in exactly the same way to maintain interoperibility. Additionally, a global database model would almost certainly require a custom built application for working with that model. This application would then have be shared among the membership because the cost of developing and maintaining such an application locally would be prohibitively high.
With the DEF each herbarium can pick and choose the portions of the data model they find useful, thus allowing them to store their data in the most effective format for them. This also allows the membership to develop inexpensive methods of data management. Data management applications can then range from a simple MS-Access data table up to a SQL server based system and the import and export of the data can be handled by the standard delimited acsii file format.
The data model that Tracy uses consists of two main parts.
The first part of the model is the Collection data table. This table
holds all of the information about the specimens in the herbarium and is
loosely based on a subset of the DEF. The information stored is as
· CollectionID - Four char acronym for the collection containing the specimen
· CollectorSpecID - ID Number the collector gave the specimen
· BeginDate - Date specimen was collected or the first day of a multiday collection
· EndDate - End of a multiday collection
· OtherDate - Space for non-specific dates ( Summer 1885).
· UserID - ID of the user who entered the data.
· EntryDate - The Day the user entered the data
· EntryTime - The Time the user entered the data
· PlaceName - A particular place the specimen was collected from.
· Cultivation - Was the specimen from cultivation
· LocalCollectionID - TAMU Herbarium specific field
· PlaceID - TAMU Herbarium specific field
· Nomen - TAMU Herbarium specific field
This is a simple data model, especially when compared to models
from a number of other projects. This model was chosen for four reasons.
First the notion that one can completely define what is needed by the taxonomic
researcher a priori has proven again and again to be false. Attempting
to define a large all inclusive model was judged to be unwise at this stage.
Secondly, a large complex model with a lot of typical relational
database style integrity and lookup constraints was too complex for the
majority of our target user base to use effectively . Third, given
the equipment and technical administrative personnel that the member
herbaria were likely to have available over the long term, it was determined
that a system based on a PC class machine was better suited to the task
rather than a Workstation based SQL server. This leads to reason
four: To get the performance required for rapid entry of the data
we could not implement a complex data model on PC based SQL server.
Therefore a simple table structure was indicated. The resulting system
has proven to be very quick for data entry and querying.
Features of Tracy
While not part of the data model itself, the BONAP data is an important
part of the system. The fields "family", "genus", "species", "tri",
and "quad" benefit from the BONAP data in the following way. When
the user begins to enter a family name, he can activate the drop down list
of the family control. This list may contain any subset of the 240+
families that are contained in the BONAP data. For example, if the
user selects the family ACANTHACEAE (either by mouse or by partially typing
the name at which point the system highlights the ACANTHACEAE string and
the user simply hits return) and then moves to the genus field and
activates the drop down list he is presented with all the genera that are
in the ACANTHACEAE family. Upon selecting a specific genus (say Ruellia)
and entering the species field the user can then select from a list of
species specific to the ACANTHACEAE Ruellia taxon. This continues
all the way down to the Quad level. At each point when the user has
indicated a name that is in the BONAP list the codes for that name will
appear in the BONAP Name ID and Taxon ID fields. The
BONAP data is stored in a specially encoded data file that is accessed
by Tracy at startup. It then provides essentially instantaneous
access to all 70K+ names in the BOANP list.
Another feature of Tracy is the various drop down lists for some of
the fields in the Collection data (as listed in the second part of the
data model above). Each field behaves in the following manner:
Tracy allows the user to access each
of the tables listed above to edit the values that may appear in the
In this same vein are the "use last" buttons. For nearly all
of the subsections in the Edit Record form, there are small unlabeled buttons
in the upper right hand corner. Tracy is designed so that
the user never has to remove their hands from the keyboard to enter data.