Actor histories return archival description results during search when linked as subjects
|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|
- 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"
- BAR is returned when searching for peanut
- 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.
#1 Updated by Dan Gillean over 5 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