Agents are people, organizations, groups, code, or any entity that performs actions. Agents are collectors, authors of publications, users of objects, issuers of identifiers and, if you enter or edit data, you are an Agent. A single Agent can have many roles and many names. No matter how many roles or names an Agent has, there should be only one Agent profile in Arctos to represent them.

Agent Type

Agent Type is controlled by a code table. All Agents must have a unique preferred name.


Data about a person-agent can include first, middle, and last names. Prefix and Suffix should only be included in preferred name to disambiguate people if necessary. For example, the following might all apply as name type aka to one agent:


Examples of organizations include:

Agencies can have hierarchical relationships, e.g.:

For catalog record roles person agents are more explicit and preferable to organizations. Organizations are generally more useful in transaction and project roles.


A group is two or more agents functioning in some named capacity. So, instead of listing several collectors on an expedition, one might make all the collectors members of something like the “1994 Swedish-Russian Tundra Ecology Expedition.”

Agent Groups consists of:

  1. An agent of type=organization, and optionally
  2. person agents associated as group members

Groups may be useful for things like collecting expeditions and classes.

Verbatim Agent Attribute

The catalog record attribute verbatim agent allows uncontrolled strings to be associated with individual catalog records.

This is preferable to creating low-data Agents when possible, and puts any necessary cleanup in the context of the catalog record data. For example, when working with bare agent names (as is often the case when importing data to Arctos), deciding if “J. Smith” and “J. D. Smith” are the same Agent is often impossible or impractical. Determining whether similar strings represent one entity is a much more robust exercise in the context of multiple catalog records, where it’s relatively straightforward to determine if the potential agents are conducting similar activity (in which case they probably are the same, and it’s easy to Agentify them using Arctos tools) or if they are probably different (in which case more research may be necessary, or multiple agents with differentiating relationships and addresses may be created and used). We recommend this approach for most incoming string-based “collector” information.

This data structure is suitable for any agents acting in any “role”. Attribute method is required in order to differentiate intended roles for verbatim agents.

When “bad duplicate of” agents are merged, verbatim agent Attributes for collector roles are automatically created for all affected catalog records.


All agents must have one and only one preferred name and one and only one login. An agent can have any number of other names.

Name Type

Agent Name Type, e.g. “preferred,” is controlled by a code table.


See Address Documentation

Pro Tip

ORCiD and Wikidata urls are found in the addresses section of the agent table.

Agent Status

Agent Status is controlled by a code table.


Remarks is a good place to include a description of the Agent or their activities. Anything that might be helpful to other users in understanding who or what the agent is should be included.

Pro Tip

Never use remarks for data which can be linked or formalized elsewhere.

Agent remarks allow for free text descriptive information and can also include HTML to make text more readable on the Agent page.

Pro Tip

You can use an HTML cheat sheet to help with the code. Try HTML Cheatsheet or Stanford HTML Cheatsheet

Identical Agent Names

Identical agent names, between and among agents, is different than identical agents. Duplicate agents are two or more agent records that mean the same physical entity (THAT PARTICULAR John Smith; US Fish and Wildlife Service). It is not necessary for duplicate agents to share a name; in fact, they are often introduced because of misspellings. The “Agent Activity” link is a good place to make sure you’re dealing with real duplicates.

Not Duplicates

Occasionally, it will be determined that two agents are not in fact duplicates. The only action that will stop future attempts to merge them is a “not the same as” relationship. Document the relationship in remarks, but do not try to build functionality into remarks.

How To

Instructions for doing specifc tasks related to Agents in Arctos

Edit this Documentation

If you see something that needs to be edited in this document, you can create an issue using the link under the search widget at the top left side of this page, or you can edit directly here.