Back to Tracy
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. 
 

Data Model 

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 follows: 
 

    · Accession  - Accession number of the specimen. 
    · CollectionID  - Four char acronym for the collection containing the specimen 
    · BonapNameID 
    · BonapTaxonID 
    · Family 
    · Genus 
    · Species 
    · Tri 
    · Quad 
    · CollectorName 
    · 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. 
    · County 
    · State 
    · Country 
    · Cultivation    -  Was the specimen from cultivation 
    · Notes 
    · LocalCollectionID     -  TAMU Herbarium specific field 
    · PlaceID   -  TAMU Herbarium specific field 
    · Nomen   -  TAMU Herbarium specific field 
Note that some of the fields are not present in the DEF (e.g. . LocalCollectionID, PlaceID), but that the majority of the fields are. 

The second part of the data model consists of tables that provide data values for the main collection table’s fields.  The lookup tables that are available are: 

    CollectionID 
    CollectorName 
    PlaceNames 
    Counties 
    States 
    Countries 
Each table is used to store information that Tracy can present to the user at the time of specimen entry.  This allows the user to select complex names or common names from a drop down list without having to type the entire name string  into the system every time(see below). 

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 

BONAP Data 

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. 

Drop Down Lists 

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: 
 

  • The user is entering data about a specimen and comes to the collector name field. 
  • They activate the collector drop down list and begin to type the collector name. 
  • If the collector name is in the drop down list then they select it and move on.  If not then the user finishes entering the name and then moves on. 
In this situation, the system notes that the user did not find the name in the drop down list and so the system adds the name the user enterd  to the data table for collectors and adds the name to the drop down list.  The next time the user begins to enter that particular name they will find it in the list and thereby avoid typing the whole name again.  The advantage of this type of operation is that the collector name table can be initially filled with the names of the most prodigious collectors.  But less well represented collectors can be added at specimen entry time for relatively little cost. 

Tracy allows the user to access each of the tables listed above to edit the values that may appear in the lookup tables. 

Speed Buttons and Data Entry 

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. For example: 
 

    After the user enters the Accession  he hits the tab key to move to the Collection ID field.  If he has the CollectionID set to a default value then he does  no more than hit the tab key again and the CollectionID field will automatically be filled in.  The system then moves the input focus to the "use last" button in the Taxon subsection.  If the specimen he is entering is the same as the one they entered last time, then he simply hits the space bar to activate the button.  The system then fills in the Taxon fields with the previous values and moves the input focus to the Collector subsections use last button.  This  process repeats itself for each subsection in the Edit Record form.     At the end of the form, the system will move the input focus back up to the "new record" button.  If the user hits the space bar to  "click" this button  then the data just entered will be posted to the data table and the system will again move the input focus to the Accession field and then will be ready to enter data on the next specimen. 
     
Notice that at no time does the user need to remove his hands from the keyboard to move the mouse.  This can dramatically speed up user input since the user can learn the "patterns of interaction" of the system and thus operate the system more efficiently.  The "use last" buttons can also reduce hundreds of key strokes down to one if the current group of specimens share taxon, collector, or locality information. 
 


Stand Alone vs Centralized Data 

Stay Tuned...