Add to Current update request

Best Practice - Creating Meaningful Agents

What is an Agent? Before you make any decisions about one, you should know what it is. Start by reading the Agent Documentation.

Caution

Agents are shared by all Arctos members. Always use caution when creating or editing a shared resource and make sure that others who might be affected by a change are notified beforehand.

General Recommendations for Creating Meaningful Agents

We recommend working with an experienced Arctos operator if you have a lot of people names to review. Below are some general recommendations for creating meaningful agents.

Avoid Duplicate Agents

No matter how many roles or alternate names a person or organization has, a single Agent should be in Arctos to describe them. Multiple Agent records which in fact refer to the same entity can be difficult to discover. Before new Agent records are created, the database should be carefully queried to check that the “new” Agent is not already in Arctos. Some examples of things to look for include:

For legacy data, the above can be a difficult standard. Are Robert Smith, R. Smith, and Bob Smith three agents or one? Sometimes, the activities already recorded for an agent makes the answer clear, e.g., there were probably not two Eleazer Fitzgarrolds collecting grasshoppers in northern Madagascar in the 1930s. (If you are viewing an agent record, the “Agent Activity” link will show you all of the agent’s actions that are recorded.) Thus, it is useful to provide as much information as possible when creating and editing agent records. If you can figure it out, the database can usefully handle the information. If you cannot figure it out it probably doesn’t matter; having multiple agents collecting under the name “J. Smith” doesn’t really affect any conceivable use of the data, and if one of the agents distinguishes themselves somehow (e.g., through publications), it’s easy to split the combined agent.

Before creating an agent, thoroughly search to be sure the agent is not already in Arctos. Use the “clear form” button to ensure that you aren’t accidentally limiting your search. Using only the “any part of any name” option, search for last name, and especially in the case of “foreign” names, search for the substring that might have been transcribed or transliterated in varying ways. If you have a “McDonald,” search for “donald” to include the possibility of “Macdonald.” Given Чернявских, search for “herny” to include Chernyavski, Tchernyavski, and Chernyavsky. (Please flag any “bad duplicate” agents you find as such during this exploration.) Consider common variations – a “Robert” might exist as “Bob,” for example.

If you have a lot of names to check, you can use the Agent Name Splitter Tool to find exact matches as well as names that are similar. If there are no current Agents that use a name you have searched, you are good to go. If you discover Agents with a similar name, make sure that they are different people so that you don’t create a duplicate Agent.

Agents with Little Data

Consider not creating an agent at all. The catalog record attribute “verbatim collector” exists in part for linking ambiguous or low-value collector strings to catalog records and may be an appropriate choice if the agent is relatively unknown, unlikely to become known, and has no or little other activity. For example, “fisherman” is almost certainly better recorded in the verbatim collector attribute.

Agent unknown

Use the Agent “unknown” when the person or organization doing the collecting, identifying, borrowing, etc. is unknown or unclear. Please do not create new Agents such as “Collector unknown” or “Determiner unknown”. Consider using “unknown” along with the verbatim collector attribute rather than creating cryptic agents such as A.B.C. or S. Smith. If at some point in the future the full name of collector, determiner, or borrower S. Smith is determined to be Susan B. Smith for a specific set of records, add the full Agent name to Arctos and assign the records appropriately

Do

Don’t

Abbreviation Exemptions

Abbreviations are to be avoided, but there are a few exemptions:

Ambiguous Agents

When managing Agents, often only limited information will be available. “Is J. Smith the John Smith I’m looking for?” may have no clear answer. The Agent Activity report will provide a summary of all that’s known; often dates or places can be vital clues. (A different browser or private tab may be used to query collections to which one does not have Operator access.) An email to anyone using the existing or suspect agents may turn up more information.

Sometimes the data in Arctos cannot provide a clear answer, and a somewhat arbitrary choice becomes necessary. We suggest the choice between creating potential duplicates and “overloading” Agents is not as arbitrary as it may first appear; the “correct” choice among no truly correct choices is generally to create fewer Agents rather than more.

Overloaded Agents

Overloaded Agents - Agent records which in fact represent multiple entities - are easy to discover. A search for the proper spelling will not find records linked to a mis-spelled Agent, and users will often continue to explore. (Users searching by agents generally know something of the agent in which they are interested.) When attached records are found, they will often contain information leading to the correct interpretation of the data: The alleged entity collected before they were born, or were collecting fossil molluscs in Alaska and extant grasshoppers in Madagascar at the same time. This information can easily and immediately be used to exclude the records which are not of interest or, for curatorial users, to split the agent and create a ‘not the same as’ relationship to prevent subsequent confusion.

Different Agent, Same Name

Occasionally, two distinct agents will share a name, but there exists a unique key on preferred_name so duplicate preferred names are not possible. With some research, it is usually possible to disambiguate the agents by adding initials, middle names, or nicknames. If that is not possible, it may be necessary to add parenthetical information to the preferred name, for example “John Doe (southwest mammals).” When this is necessary, it’s usually preferable to similarly annotate all agents that share the name to avoid later data entry efforts inadvertently picking the wrong agent. Add a “not the same as” relationship and verbose agent remarks.

Without the unique key, applications which use strings to identify agents, such as the catalog record bulkloader, cannot use preferred names, and it becomes necessary to add unique aliases to pick agents. (Internal forms pick by agent_id and names are only “human-readable proxies” to the ID.) The current unique index approach seems less problematic than the alternative, both in getting students to choose the correct agent and in avoiding duplicate agent creation, but neither method is ideal. Address any suggestions or concerns to the Arctos Working Group.

Agent Relationships

Relationships between agents can be recorded. Like date of birth and date of death, relationships can be critical to understanding duplication and similarities in names, and in understanding relationships within the literature, taxonomic opinions, etc. The pull-downs are self-evident. If you know of a relationship between agents, please record it. The relationship “not the same as” can be useful in understanding that suspiciously similar names are not duplicates, but do in fact refer to separate agents.

Summary

Edit this Best Practice

If you see something that needs to be edited in this Best Practice, 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.

Community Discussion