The steps in the Module 1 workflow are as follows (Fig. 2):

1. Curators prioritise taxa to be digitised, and prepare and collate all relevant specimens, which are often stored in different locations. A taxon-based approach to digitisation simplifies the process for digitisers who may not be familiar with the organisms.

2. Drawers are delivered to digitisation stations (by curators and/or digitisers) and stored there temporarily while being digitised.

3. Data managers allocate unique numbers to be used as barcodes.

4. Barcode labels are printed at an appropriate size, depending on the size of specimens being digitised. If labels are misplaced, the corresponding barcode numbers are discarded. Steps 3 and 4 together provide uniqueness of object barcodes.

5. The first (preparator) digitiser takes a specimen from its drawer, removes its labels and pins it into a unit tray of appropriate size. The labels are placed on the raised section on the right side of the tray next to specimen. If the specimen does not have a unique ID, a barcode label is added. For specimens that have already been databased, barcode labels are not printed (approximately 1% of specimens).

6. Sixteen specimens are prepared in this way at one time and arranged in a temporary storage drawer prior to imaging.

7. The second (imaging) digitiser takes the prepared drawers, removes a unit tray for imaging, and photographs the specimen and labels. Double-sided labels are photographed from both sides, resulting in two label images per specimen. Images are stored initially (and temporarily) on the local computer HDD.

8. Labels are then reattached to the specimen, which is pinned into a new, permanent drawer. The remaining 15 specimens in the temporary drawer are imaged in the same way. This process is repeated until either the new drawer is filled or the taxon unit is completed. Preparation of specimens takes approximately the same time as imaging and re-housing (see Discussion: Digitisation performance).

9. The new drawers with digitised specimens are returned to the collection space.

10. For each specimen drawer, a folder is created on the server, with subfolders reflecting its taxonomic content. Images are then moved from the local computer HDD to the appropriate folder and subfolders.

11. When each specimen lot (taxonomic unit or drawer) is completed, the imaging digitiser moves the acquired images to a designated server location, maintaining the folder structure (Drawer#/Taxonomic name).

Compromises were necessary at this and subsequent stages to optimise overall productivity (see Discussion). The total number of imaged specimens and numbers of images are shown in Table 1.

Module 2 consists of several consecutive steps (Fig. 3):

Software development [1-4]

The NHM’s KE EMu (© Axiell) collections management system is unsuited for rapid data entry and includes few tools for data processing. Therefore, we developed a separate Microsoft SQL Server database (the “iCollections database” [2]) to support temporary storage and processing of transcribed data. A graphical user interface (the “iCollections interface” [3]) was developed using MS Access 2010, and provided data transcription, management and processing tools, as well as user administration and reporting capabilities. Considerable effort was invested in optimisation of the user forms to ensure that they were intuitive to use and supported a natural flow of activities.

Scripts [4] were developed to process images, extract metadata from the folder structure, read barcodes from photographs, and import image metadata into the iCollections database.

Database population [5-12]

A list of accepted UK lepidopteran taxon names [6] was downloaded from EMu [5] and used to seed the iCollections database lookup taxon list [7]. This is not required but saves time later in the process. Site and collector data could also have been seeded had appropriate data been available.

Users were added to the database, and assigned one or more roles (e.g., transcriber, georeferencer). The system uses these roles to control user access to application functionality.

Scheduled scripts traverse the image storage folders [8] overnight and perform the following operations for each image [9]:

1. Crop the right 25% of image showing the specimen’s labels, resize it to 800 by 1219 pixels and save it as a new file with the original filename suffixed with “_label”.
2. Read the embedded barcode from the new label image.
3. Rename original specimen and label images using the barcode as filename and retaining the “_label” suffix (if barcode recognition is unsuccessful, the original file name is retained).
4. Create a specimen record in the iCollections database, including the taxon name and drawer location (read from the folder path) and the specimen barcode.
5. Create image records, including the image path and filename, associated with their corresponding specimen records.

This produces a record for each specimen, typically linked to 2 image records – the full specimen image and the labels crop [10-12]. This process is scheduled, so once images are deposited on the server, corresponding records are automatically generated in the iCollections database.

Transcription [13-15], Fig. 4a

Once the database is populated, a data manager can allocate specimen records to available transcribers [13]. When a transcriber logs into the application they only have access to those records allocated to them. The data manager may also reallocate records if necessary (e.g., to optimise transcriber effort or cover absent staff). This pre-allocation of records simplifies aspects of workflow management, and increases the likelihood that digitisers will work on sequential specimens from one site, helping to minimise interpretation errors.

The transcription interface displays the label crop (if necessary the digitiser can view the corresponding specimen image) and fields for entering or selecting data values [14-15]. Considerable effort was expended to ensure that the interfaces were simple and intuitive to use, supported a natural flow of activities and presented unambiguous choices wherever possible.

Transcribers can access records they have worked on previously, which is vital in allowing them to compare labels or to correct transcriptions if new labels indicate a previous error. This facility to return to and correct previously transcribed records also reduces the pressure on transcribers to “get it right first time”.

Transcribers were asked to capture various data elements from the labels, primarily dates, site and collectors. They were able to indicate uncertainty for some data elements, allowing for later scrutiny and resolution by a subject matter expert (usually a curator). Records with technical issues can be referred to a data administrator. Transcribers are also able to correct barcode misreads (which the application indicates) manually, forcing renaming of the associated image files, and maintaining the correspondence between barcode and filename.

The transcription process was designed specifically to capture verbatim data, without interpretation. As new sites or collectors were encountered on labels, transcribers were able to add them to the database, after which they were visible to all other transcribers and selectable from drop-down menus, reducing the need to key data and the risk of transcription errors.

This separation of transcription and interpretation has two significant implications for site data:

1. A digital version of the verbatim label data is recorded for each specimen.
2. Numerous different renderings (or “variants”) of the same physical site are captured (e.g., “Reading”, “Reading, Berks”, “Redding”), requiring a subsequent normalisation process to remove logical duplicates and standardise the records.

Data normalisation [16-21], Fig. 4b, c, d

Both taxon and site “variants” (different literal transcriptions of the same logical concept) are processed by subject matter experts (curators/taxonomists or georeferencers) via the iCollections application. Each variant is assigned to a separate “master” record, which is a standardised version of the concept represented by the variant. The interfaces show the list of variants to the left and allow a user to associate them with a master from the right-hand list. Users may also create new master records as appropriate.

For example, taxon variants “Aus bus” and “A. bus” might both be associated with the single taxon master record “Aus bus (Linnaeus 1758)” [19-21].

Similarly, “Reading”, “Reading, Berks” and “Redding, Berks” variants would all be associated with a single “Reading, Berkshire, UK, Europe” master record. This significantly reduces the georeferencing burden – the reduced set of masters effectively covers all the associated specimens (Table 2) [16-18].

When complete, normalisation ensures that all specimens from a single location or taxon are linked to the same, standardised representation of that location or taxon concept, effectively deduplicating the raw variants [18, 21].

Note that variants and masters are, logically and physically, separate database entities. Variants represent verbatim and/or historical site or taxon strings, each stored just once to ensure transcribers are not required to rekey the same values repeatedly.

The normalisation processes can run in parallel with transcription, with subject matter experts normalising sites and taxa as they are generated by the transcription process.

The site normalisation interface includes a georeferencing tool, so the normalisation and georeferencing processes are typically, although not necessarily, performed simultaneously by one user (Fig. 4d).

Scrutiny

Users with the “scrutineer” role have access to the raw data for quality assurance purposes. They can filter and sort specimen records in a traditional data grid, then view and edit the full details of any individual specimen.

This allows data administrators or subject matter experts to more easily identify, assess and remedy data quality issues, including accessing those records that digitisers have flagged as needing expert attention.

Scrutiny was not a formal step in the workflow, but was performed as required at any stage.

The iCollections application includes a simple georeferencing tool that allows a user to acquire point and extent data from Google Maps (Fig. 4d). We follow the NHM Georeferencing standards (Suppl. material 2), which give specific and repeatable methods of georeferencing features or places. These can include precise localities such as 4km along the A9 from Perth, nearest named place or the mouth of a river. By following the NHM guidelines we have standards that can be replicated and are based on best practice and are freely available at the NHM.

The Georeferencing process is split into five broad stages (Fig. 5).

1. During this stage we only georeference sites with at least five collected specimens. This enables sites with many specimens to be georeferenced quickly, which can account for 60-70% of each collection [1-3].
2. The team splits the remaining data into two parts A-M and N –Z, and each georeferencer spends no more than 15 minutes on each site attempting to georeference the data [4].
3. The remaining data are checked by the team leader and questions answered if possible. The data are then investigated further by the georeferencers and the specific curator /researcher, who provide help on any specific problematic locations [5].
4. The remaining data are checked by the team. Sites that cannot be georeferenced are noted as “un-georeferenceable” in the data [6-7]. The accuracy of the data set is checked by selecting 100 sites at random from the data and comparing the results of two independent georeferencers.
5. The data are then exported and ingested into KeEMU by Database team [8].

EMu records reference other records within the system via IRNs (Internal Record Numbers – unique record identifiers) according to the schema shown in Fig. 6. Records must exist before being referenced, so the order in which entities are imported is critical. Where possible, pre-existing CMS records are referenced (to avoid duplication). So iCollections records are compared with those already in EMu, and any IRNs for pre-existing records are recorded in iCollections, allowing new records from iCollections to reference pre-existing EMu records.

Thus, for each referenceable record type (image, collector, site, collection event or taxon) the following steps are required (Fig. 7):

1. Create new EMu records of an appropriate type, if not already present.
2. Retrieve matching EMu IRNs and store with corresponding iCollections records (for later use as a reference).

After Quality Control (QC) [1], transfer of data from iCollections [2] into EMu [3] is a multi-stage process, with new entity records being ingested into EMu and EMu IRNs (except those for specimens) returned to iCollections [4-10]. This process is mediated primarily by generation of csv reports containing new records from iCollections and corresponding IRNs from EMu.

Data embargo procedures are then applied as appropriate [12-15] before both images and specimen data are released through the NHM Data Portal (data.nhm.ac.uk) [16].

Once Data Managers are assured that specimen records have been ingested correctly, they have no further utility in the iCollections database and may be archived.

• Ideally, physical curation of the collection should be undertaken as a preliminary step before digitisation. However, in the present implementation, the collection had to be moved from old drawers with a cork lining to new, plastazote-lined drawers. Thus, to minimise specimen handling and potential damage arising therefrom, collection re-housing was combined with imaging.
• The most effective way to image specimens within the project was for digitisers to work in pairs, rather than individually or as part of a ‘production line’. This proved to be a flexible means of tackling the digitisation of butterfly specimens. Each pair worked on a separate species. If species were represented by more than one subspecies, then these were sorted prior to imaging, which increased work rates. The digitiser pairs collaborated to solve problems as they arose and to develop effective solutions.
• The use of in-camera high quality JPEG images instead of uncompressed file formats reduced post-processing time, file number and disc storage requirements. Image quality was determined as sufficient for research and curatorial purposes and this format needed no further editing for display on-line. The original master images will be stored in a digital asset management system (DAMS) that prohibits unauthorised editing, so the risk of unintended compression (should a user re-save a JPEG) is negligible.
• The use of standardised unit trays saved time when framing and focusing.
• Image consistency was ensured by use of identical light boxes and a standard white balance setup.
• Temporal separation of imaging and transcription made import and data checks easier for data managers and curators. Periods of three weeks’ imaging were followed by approximately one week of transcription that involved all digitisers. Georeferencing, a completely independent stage in the workflow, typically started much later to allow accumulation of sufficient transcribed records for frequency analysis.

• Wherever possible, image processing and data capture were automated so as to populate the database rapidly prior to transcription, and to facilitate transfer of images and metadata to KE EMu. This minimised impact on the transcription process (by not diverting digitiser effort) and reduced the potential for errors.
• Extraction, down-scaling and sharpening of the label area of the specimen image increased speed and accuracy of barcode recognition.
• Cropping of the label area, barcode recognition and file renaming was scheduled as an overnight batch process. The database was pre-populated with drawer, label, barcode and taxon data using a script that navigated and read the folder structure of the file system: Drawer ##/Taxonomic name/Barcode ##.jpg.

Transcription aimed to capture data for both curatorial and research purposes. However, it proved impractical to transcribe absolutely everything on the labels (due to, for example, cryptic conventions, abbreviations and/or non-standard characters/symbols on labels), so transcription focused on a restricted number of core data components (Table 4).

The taxonomy normalisation step is necessary to remove erroneous taxonomic names (e.g., due to mistyping at the imaging stage or incorrect drawer labelling) (Fig. 4b). Such names are linked by curators or collections managers (as taxonomic experts) to the appropriate name in the master list (new master list entries being created as necessary). Likewise, the site normalisation step is necessary to reduce the number of sites that have to be georeferenced. Both of these processes facilitate the eventual import of the data from the iCollections database into KE EMu, with the minimum conflict with pre-existing data types (Fig. 7). Existing records in KE EMu should be used where available and possible, but for some data components new KE EMu records have to be created and other adjustments made (Table 5).

When importing records from iCollections to EMu it was important to avoid creating duplicates, so iCollections records needed to be either (a) matched to an existing record of the same concept in EMu, or (b) imported into EMu as new records. The action(s) taken for each entity are listed in Table 5.

MS Access was chosen primarily for its speed and the ease with which comprehensive and functional data interfaces can be created. Its flexibility and compatibility with existing NHM IT systems and skillsets were also significant factors.

Quality control and assurance (QC/QA) procedures are implemented at all stages of digitisation so tackling data quality is a multifaceted task involving different teams and expertise (digitisers, data managers, curators and georeferencers). Errors may occur at any stage of the digitisation process or be present in the original label data. Errors are inevitable and so a strategy is required to minimise, catch, categorise and resolve them. QC/QA procedures aim to ensure correctness, completeness, and consistency of data.

Principal sources of errors:

• Digitisation process errors:
  • Imaging (upside down, blurred, multiple, wrongly associated, missing).
  • Barcode (misread, no barcode, two barcodes).
  • Wrong taxon.
  • Wrong drawer.
  • Non-British specimen.
• Transcription errors:
  • Unreadable labels (poor handwriting).
  • Misinterpreted data (‘coll’ => collector or collection, incorrectly assumed century).
  • Missing information (information accidentally skipped).
  • Errors on the data labels:
    • Conflicting localities.
    • Wrong dates.
    • Multiple/erroneous registration numbers .

The principle QC/QA measures taken were:

• Normalised database structures with appropriate indexing and data validation rules.
• Visual highlighting of specific issues (e.g., barcode read failures) in the transcription interface.
• Automated scripting for file management (renaming, cropping and copying) and data import/export tasks.
• Option for transcribers to flag unclear records for escalation, either ‘for scrutiny’ (curator) or ‘refer to admin’ (data manager), and resolution.
• Data checks in the backend databases at different stages, both pre- and post-import.
• Documented data capture protocols, training and support.
• Vigilance and diligence of digitisers, data managers and subject matter experts.

To provide a baseline for digitiser performance in similar future projects of pinned insects, we timed the tasks performed by individuals throughout the project. The data were analysed and compared with timings measured for similar projects (e.g., the Diptera Digitisation Project). Base performance (E) was estimated using a three-point method with following parameters: a, the minimum time as a best-case estimate; b, the top 90% of maximum time, a worst-case estimate; and m, the median, 50%, chance of completion, a most likely estimate. Performance is then calculated using the formula:

\(E = (a+4m+b) / 6\)

with the standard deviation estimated as

\(SD=(b-a) / 6\)

which is widely accepted in management and information systems as producing good project estimates based on limited information. Digitisation time per specimen varies greatly and depends on taxonomic and geographic breadth of the collection and its curatorial quality. Generally, British butterflies and moths were collected in relatively few localities (<5,000), so transcription and interpretation of labels was easier and faster (37.6 specimens per site in average) than for the Diptera collection, which had a similar number of sites, but worldwide, and fewer specimens (8.4) per site. Handling smaller specimens also takes longer (Table 6). Georeferencing times cannot be calculated directly based on number of specimens, but only estimated based on sites due to the nature of georeferencing process. Approximately 300-350 site variants can be dealt with by one person per week.

In total, 13 people were employed as digitisers for a total duration of 264 months, of which 197 months were spent on the iCollections project (Table 7). Additional direct costs included equipment and consumables, and refurbishment of the digitisation suite. However, the total cost of the project to the NHM is much higher, as that also includes the salary costs of all involved personnel: curators, researchers, IT specialists, data managers, facility managers and administrative staff. These costs are particularly significant during the initial planning and set-up stages of the project, but may be partly reduced in future projects once workflows and protocols have become established (for example, compare the costs of the earlier Butterflies and the later Moths subprojects in Table 7).

In assessing the economics of the iCollections project, we have included all relevant costs, particularly those relating to institutional infrastructure, as we consider that these staff and their associated costs are often overlooked by other digitisation projects. These are true costs, which, while not always acknowledged in funding applications, do nevertheless support critical activities. For example, interface development, together with data transfer and storage, is heavily reliant on institutional infrastructure and access to relevant personnel. In developing iCollections we found that the project required interaction with many different areas of the NHM: human resources, administration, curation and research. As with digitisation performance, costs are also incurred depending upon the nature and curatorial quality of the collection. The better curated the collection, the fewer extra staff will need to be involved in the project and thus the less expensive will be its digitisation. The easier specimens are to handle and the narrower the scope of the project (taxonomic and/or geographical), the less time will be spent digitising each specimen.