Image Submission

File storage for the label images will be handled by the ADBC HUB (iDigBio). Image submission will take place using password protected FTP. To obtain connection information for the FTP site and have an upload profile created for you, email Robert Anglin or Edward Gilbert. Once submitted, images will be processed to create three web versions (basic web, thumbnail, and large) that are placed on a web server and linked to specimen records located within the lichen and bryophyte web portals.

Workflow

  1. Image specimen labels using your preferred workflow. Images are expected to follow these rules:
    • Images must be saved as JPGs.
    • Images are named using the unique specimen identifier (i.e. barcode) using a consistent naming convention. This identifier is used to link the images to their proper specimen record.
  2. Load the images on to the FTP server. FTP connection information will be supplied to each provider upon request. Each herbarium has a folder within the FTP base folder. Within these institution folders, one will find “lichens” and “bryophytes” folders. Since lichens and bryophytes have their own data portals, make sure to process the lichen and bryophyte images separately by placing them in the correct upload folders.
  3. Load skeletal data files into same folder as images. This file contains specimens data recorded during the imaging process, such as most recent identification, catalog number (accession number), collector, collection number, collection date, exsiccati name, exsiccati number, etc. Submission of these files is not required, though strongly encouraged. Recording the most recent identification at time of imaging is especially important since it is not always possible to determine filing information from the specimen image alone. This is a particular issue with collections that annotate specimens by simply filing the specimen under the new identification without attaching a formal annotation label. The skeletal data files are expected to adhere to the following rules:
    • File should have a file extension of .csv, .txt, .tab, or .dat. For example, skeletal_12Dec2011.csv, ABC_skeletal_12102011.txt, etc.
    • File can be comma, tab, or pipe delimited. Files with .csv extensions are expected to be a standard comma delimited file (CSV). Files ending in .tab are assumed to be tab delimited. Files with .txt or .dat extensions will be analyzed to determine the delimiter. Note that Excel has the unfortunate tendency to automatically format numeric fields, remove leading zeros, modify date formats, and sometimes assume lat/longs should be rounded to the nearest cent. If you open the skeletal records in Excel for review, it is highly recommend that you do not save the file!
    • CatalogNumber is the only requiered field since this is what is used to link the data to the correct images. All other fields are optional, though the most recent indentification fields are strongly encouraged. Most recent identification can be placed within any of the following fields: scientificName (if with author), sciname (without author). Or separate fields can be used for: genus, specificepithet, taxonRank, and infraSpecificEpithet.
    • The first row should contain the field (column) names. The field names should follow those approved for upload to the web portals (Symbiota platform). Most Darwin Core fields are importable within the Symbiota portals. A few additional fields are also acceptable. See the Symbiota Import Quick Guide for a list of fields typically imported into a portal. Note that while field names are not case sensitive, they must match the naming format exactly used within the portals (e.g. no spaces).   
    • Unique identifier (barcode number, accession, database pk, etc) must be supplied for each record to be loaded. If left blank, the record will be skipped. This field must be named catalogNumber. The identifier must follow the same format used for within the image file names.
    • Note that a Skeletal Data JAVA application has been made available through this project. This application is to be used during the imaging process to aid in renaming the images using the barcode and collect skeletal data. The resulting CSV skeletal data file can then be uploaded processed along with the images.
  4. Loading scripts will be triggered nightly to process images and skeletal data skeleton files.  

General Notes

  • For both image and skeletal data records, the unique identifier is used as the central link between the specimen records and images. If a specimen record does not already exist (typically the case), a new record will be created, populated with the identifier, and assigned a processing status of "unprocessed. Information from skeletal data files will be appended to these records. If a record already exists, images will simply be linked to the existing record and tagged as needing review.
  • Record data from a skeletal data file will be appended to an existing record without copying over any existing information. If there is already data within a field, new skeletal data that contradicts the existing data will be appended to the general notes field (occurrenceRemarks) with a clear indication of which field the data belongs.
  • Images loaded more than once will replace existing web images. This is a nice method for replacing faulty images (e.g. out of focus). However, it should be noted that if the imaging workflow incorrectly names a new image with the same name as an existing image, the good image will be replaced with the bad. If multiple images of a single specimen are to be loaded, make sure the file names are unique. 
page tag: 

This material is based upon work supported by the National Science Foundation grant ADBC#1115116. Any opinions, findings, conclusions, or
recommendations expressed in the material are those of the author(s) and do not necessarily reflect the views of the National Science Foundation.