Bug #8128

Actor histories return archival description results during search when linked as subjects

Added by Dan Gillean about 7 years ago. Updated almost 6 years ago.

Status:VerifiedStart date:03/23/2015
Priority:MediumDue date:
Assignee:José Raddaoui Marín% Done:


Category:Search / Browse
Target version:Release 2.4.0
Google Code Legacy ID: Tested version:2.1, 2.1.1, 2.2
Sponsored:Yes Requires documentation:


To reproduce

  • Create a new authority record, "FOO"
  • Add a unique search term to the actor history - "peanut"
  • Create a new archival description, "BAR"
  • Add "FOO" as a name access point to BAR, and save
  • Search for "peanut"

Resulting error

  • BAR is returned when searching for peanut

Expected result

  • searching for peanut does not return BAR
  • searching for peanut ONLY returns BAR if the user adds FOO as the creator of BAR (not just a name access point)
  • The biographical/administrative history for an actor added only as a name access point should not be indexed for a related information object.


In AtoM, the biographical history of an actor is not maintained in an archival description, but in the related authority record, to allow for broad reuse, and to better support standards-based practice. This practice is documented in the following:

... and other related links found on the above page.

When an actor is added as a creator, we should be indexing the biographical/administrative history, because users find it displayed in the body of the archival description view page, and expect to be able to search on that information. However, when adding an actor as a name access point, we should not be indexing the entire actor record, including the bioghist data - instead, we should only be indexing the authorized form of name for the actor as part of the related information object.

Right now, this is likely because of of the following:

In essence, we are simply importing the entire actor's indexed fields into the information object tree for every name added. We do the same for the related repository, etc - adding a lot of unnecessary clutter to the index that can muddy the search results.

Instead, we should probably start to reconfigure this - we may see some minor performance improvements as a pleasant side effect. For related name access points, all we really need in the information object is the authorized form of name. Same with the related repository.

Related issues

Related to Access to Memory (AtoM) - Bug #5944: general search returns all descriptions from a repository... Verified 11/12/2013
Related to Access to Memory (AtoM) - Task #11538: Consider returning creator histories to global archival d... Verified 09/21/2017


#1 Updated by Dan Gillean about 7 years ago

  • Target version set to Release 2.2.0

Tentatively assigning to 2.2, so as Sarah and I review the outstanding tickets and the time available, we can remember to consider this one.

First reported in the user forum, here: https://groups.google.com/d/msg/ica-atom-users/w9VRCuzFJ1E/nkaNykQYA88J

#2 Updated by Tim Hutchinson about 7 years ago

Re repositories, see #5944

#3 Updated by José Raddaoui Marín about 7 years ago

  • Related to Bug #5944: general search returns all descriptions from a repository when search string matches a string in the repository record added

#4 Updated by Dan Gillean about 7 years ago

  • Target version deleted (Release 2.2.0)

#6 Updated by Dan Gillean almost 6 years ago

  • Status changed from New to Verified
  • Target version set to Release 2.4.0
  • Sponsored changed from No to Yes

#7 Updated by Dan Gillean over 4 years ago

  • Related to Task #11538: Consider returning creator histories to global archival description search results added

Also available in: Atom PDF