Arctos Webinar Series: Transactions in Arctos (accessions, loans, permits)


Title: Transactions in Arctos (accessions, loans, permits)

Abstract: Arctos is a community of museums that collaborate to manage and host their data online. Over 3 million records are publicly available at, a searchable biodiversity database for scientific research, resource management, and education. The Arctos database is used both for querying museum records (see webinars 1 and 2) and for managing information about the collections.

This webinar will provide a short introduction to how transactions (accessions, loans, and permits) are managed in Arctos. Topics will include collection-level permissions and the basic tools for creating and updating different kinds of transactions, managing agents, and linking transactions to projects and media.

Presenter/s:  Carla Cicero and Michelle Koo (Staff Curators, Museum of Vertebrate Zoology, University of California, Berkeley).

Moderator: Erica Krimmel (Assistant Collection Manager, Chicago Academy of Sciences)

Links to any relevant pre-reading materials for best experience:

Start Date:
Tuesday, November 14, 2017 – 3:00pm to 4:00pm EST
AdobeConnect URL:

Inaugural Arctos Webinar on September 12th

Please join us next Tuesday for a webinar Introduction to Arctos as a Collection Management System and as a Community!

Carla Cicero (Staff Curator of Birds, Museum of Vertebrate Zoology at the University of California, Berkeley) & Mariel Campbell (Collection Manager, Museum of Southwestern Biology at the University of New Mexico) will present a live demo of Arctos with time for questions and discussion at the end.

WhenSeptember 12, 2017 at 3pm Eastern / 2pm Central / 1pm Pacific / 7pm UTC

Can’t make it next week? Check out our upcoming monthly webinars.

Webinar series brought to you by the Arctos Working Group and kindly hosted by iDigBio. For more on our Adobe Connect webinar platform, please see

How to refine search results

It is often useful to first perform a general search, then “search within results” to incrementally explore specimen data and reduce the results set.

First, search for something.

Sorex yukonicus currently returns 34 specimens.

At the top of the results page, click “show/hide search terms.” A form will appear.

Use the “add a row” select to add more criteria. We’ll add ID Type….

Screen Shot 2014-05-30 at 11.33.48 AM

which will create a new row in the form. Enter an appropriate value, click requery. (The select list will help determine appropriate values.) The page will reload to Sorex yukonicus with GenBank numbers.

Perhaps we want Sorex yukonicus with GenBank numbers from the Seward Peninsula. Adjust the map until only the area of interest is visible, and click “QueryByViewport” to push the coordinates visible on the map to the form.

Screen Shot 2014-05-30 at 11.50.59 AM

Requery again. The page will reload with the selected specimens, and the map zoomed (approximately – sometimes VERY approximately! – due to Google Maps API limitations) to the area queried.

Screen Shot 2014-05-30 at 11.53.04 AM

The “requery” widget can also be used to expand search. Perhaps we’d now like to find ALL specimens with GenBank sequences from the Seward peninsula. Simply click “clear” on the Identified As row and click requery.

Screen Shot 2014-05-30 at 11.54.33 AM

Or perhaps we actually want everything with a GenBank sequence that MIGHT be from the Seward – things with a maximum coordinate uncertainty intersecting our viewport. Change QueryByError? to true and click requery. It may be necessary to zoom out on the map to see the results – some specimens have very large (hundreds of kilometers) errors.

Screen Shot 2014-05-30 at 12.00.09 PM

Create a new taxon name+classification

This describes one method of creating a new name in Arctos, while bringing along classification data.

First, make sure the “new” name does actually exist….

Screen Shot 2014-05-29 at 9.56.22 AM
…and does not exist in Arctos….

Screen Shot 2014-05-29 at 9.57.25 AM

Then find the “donor” name, in this case

Find the “donor” classification, and click “Clone Classification as new name.”

Screen Shot 2014-05-29 at 10.00.14 AM

Enter the new name and the intended classification source, click create.

Screen Shot 2014-05-29 at 10.02.09 AM

You will be redirected to the edit classification page – edit and rearrange things appropriately, carefully following the embedded instructions.

Screen Shot 2014-05-29 at 10.03.58 AM

Carefully check for any now-incorrect terms that may have come along with the clone process. Click save.

Check everything again. If it all looks good, click “Edit Non-Classification Data.”

Create relationships and common names as necessary. A relationship will ensure that users searching for Otus flammeolus specimens can find Psiloscops flammeolus specimens.

Screen Shot 2014-05-29 at 10.07.20 AM

Save everything, click “Return to taxon overview” (here Review everything again.

The name and classification is now usable.

Screen Shot 2014-05-29 at 10.11.34 AM

To improve discoverability, click the “Refresh/pull GlobalNames” link to import alternate classifications from GlobalNames. The page will refresh with any available GlobalNames data. (There are none for this taxon.)

Locality Update


Locality Documentation

This document supercedes all other locality documentation.

Major changes to the model (and, partially, their implications) are summarized here.

Specimens lose their (singular) pointer to place information; cataloged_item.collecting_event_id is no more.

Geography (geog_auth_rec) exists as a parent to locality, as before.

Geology (geology_attributes) exists as a child of locality, as before.

Table lat_long is gone. Coordinates are now a part of Locality data (and recorded verbatim in collecting_event). Note that nothing suggests coordinates are determined from locality data; in this model, coordinates can stand as the primary or only place information.

One implication of this change is that there is no longer a 1specimen–>1acceptedCoordiate relationship: Any specimen can have lots of (or no) coordinates which could be considered accepted for various purposes. The FLAT data objects (which are used for specimen search and results, among other things) deal with this (kinda…) by grabbing a random set of coordinates from a random “accepted place of collection” specimen_event. Better ideas for representing the actual complexity are as always welcome.

Reports that use lat_long will no longer work. Feel free to use the data from FLAT for reports and such, but do please be aware that our world is no longer necessarily so flat and that it is possible to link a specimen to multiple events of various types. (Handy for things that spend some time in captivity, biopsies, mark-recapture data, etc.) I’m happy to help resurrect your reports – just let me know what no longer works and how it should work under the new model.

Along the same lines, the specimen_event_type vocabulary could use some help. There are currently two options, representing accepted (or NULL) versus unaccepted coordinate determinations.

Unless someone yells vigorously and soon, this will deprecate catalog.cfm – I simply don’t think it’s possible to make people aware of the complexity of the data from that form under this model.

Table Locality is now

ColumnName NULLability DataType Explanation
GEOG_AUTH_REC_ID NOT NULL NUMBER foreign key to table geog_auth_rec
SPEC_LOCALITY NULL VARCHAR2(255) Locality descriptor
DEC_LAT NULL NUMBER(12,10) Decimal latitude; eventually to be calculated WGS84 decimal latitude
DEC_LONG NULL NUMBER(13,10) Decimal longitude; eventually to be calculated WGS84 decimal longitude
MINIMUM_ELEVATION NULL NUMBER minimum numeric elevation
MAXIMUM_ELEVATION NULL NUMBER maximum numeric elevation
ORIG_ELEV_UNITS NULL VARCHAR2(30) from ctorig_elev_units
LOCALITY_NAME     Assigned unique name for the locality; useful in grouping specimens and data entry.

New table specimen_event links specimens to places.

ColumnName NULLability DataType Explanation
COLLECTING_EVENT_ID NOT NULL NUMBER foreign key to collecting_event
COLLECTION_OBJECT_ID NOT NULL NUMBER foreign key to cataloged_item
ASSIGNED_BY_AGENT_ID NOT NULL NUMBER Person who made the specimen/event linkage
ASSIGNED_DATE NOT NULL DATE date on which the linkage was established
SPECIMEN_EVENT_TYPE   NOT NULL ctspecimen_event_type
COLLECTING_SOURCE NULL VARCHAR2(60) ctcollecting_source
VERIFICATIONSTATUS NULL VARCHAR2(255) ctverification_status; “verified by %” values lock events and places.

There may be zero or many specimen_events of any type for any specimen.

All habitat information is centralized in specimen_event.

How to use DOI/PMID to create Arctos publications

As of November 2011, Arctos has undergone major surgery in how Publications are created.

First, some history:

“Formatted Publications” were dynamically created by concatenating publication information (such as title and page numbers) together with Agent Names. Along with requiring information that was not useful for locating specimens (“show me specimens published on page 32….”), this often required the creation of new agents and/or agent names. This was a lot of work for little or no return, and often improperly used anyway. A trigger used some very complex logic to pull all this together into a “proper” citation, and when that failed (e.g., due to nonstandard page numbering) you were just out of luck. We learned a lot from this structure, but it never felt quite right.

Now, the current situation by way of example. (I’m making up the details; only the publication is real. Apologies to the people whose personal details I am going to get entirely wrong.) Let’s say there’s been a loan of (very) old moth specimens to Maria E. McNamara and her graduate student Derek E. G. Briggs. This (theoretical) loan results in a (real) publication – Fossilized Biophotonic Nanostructures Reveal the Original Colors of 47-Million-Year-Old Moths. The publication includes additional authors who are not in Arctos, were not part of the loan, and who are not important to demonstrating the usefulness of our collections.

There is a DOI given in the publication. Copy that, open the “create publication” form in Arctos. Paste the DOI (10.1371/journal.pbio.1001200) excluding any prefix  (“doi:” and “” are common) into the appropriate box, and click “[ crossref ].”

The DOI lookup service was able to obtain metadata, and everything you see above is the result of that one click. If you click “create publication” at this point, you would create a usable publication to which Citations could be attached, and which could be a part of Projects.

Here, however, we wish to capture agent information for at least the two authors to whom we’ve made our earlier (fake) loan. During the crossref lookup, Arctos has first looked for agents who match the string provided by DOI, then for agents who MIGHT match the string provided by DOI. All names – not just preferred – are considered. A maximum of 5 “suggestions” are returned for each of the first 5 authors.

The first agent returned by the DOI service is Maria E. McNamara. There is no agent with the exact name “Maria E. McNamara” in Arctos, but there are 3 agents with last name “McNamara,” all suggested in the first line of the blue Agents grid. We happen to know that “Marie Englewood McNamara” is correct, so we click that entry to select her.

The second author, who we also care about because he was on the loan, is “Derek E. G. Briggs.” Derek is also a pre-existing Arctos agent, and that agent happens to have an exact-match agent string available. Arctos finds and suggests only this agent, and again one click is all that’s necessary to add him to the publication.

The third author, Patrick J. Orr, does not have an exact name match in Arctos, and does not have a last name match in Arctos, so the system has gone off looking for agents with any string matching “Orr.” In this case, the results are not useful and can simply be ignored. If Patrick J. were deemed important, he would need to be added and selected in the standard way. If there were 6 “Orr” agents, Patrick J. might still not show up in the suggest list, but could be found in the standard way of picking agents. Take-home message: The agent suggestions are just suggestions. Sometimes they’re useful, and sometimes they’re not. Make no assumptions from them.

If we select the two suggested agents and create the publication….

we can then locate it by any name of either of two the authors who we added

or anything from the “full citation”

including the authors that we did not explicitly include

but we can NOT find the publication by authors (as “Participants”) that we did not include

results in

We could have used PMID (PubMed ID) rather than DOI to roughly the same affect. Note that PMID and DOI are apparently independently created and do not return the same values (“Maria E. McNamara” vs. “Maria E McNamara,” etc.).

Formatting from either source is occasionally horrible, and you are encouraged to use the formatting tools provided (or your method of choice) to rid citations of things like ALL CAPS and missing or excessive punctuation.

Most of the time, using DOI or PMID will create better (as in fewer mistakes) publications with much less work than traditional means. The service is, however, not magic and you, the operator, are responsible for the results. Your collections may have additional guidelines as to what agents to include, or how to format publications.