Aeon - ArchivesSpace client addon - request for more field mapping options
The University of Arkansas has requested the following mapping options for the ArchivesSpace client addon for Aeon: (1) Map "conditions governing use" note to the Aeon EADNumber field; (2) map location of top container information to the Aeon ItemSubLocation field; (3) for agents that are creators, pull the name from the Sort Name field instead of the Primary Name field (which often contains only the surname); (4) Ability to import the child and grandchild container type and indicator fields (this is not included with the ArchivalObjectInstance field in the addon); (5) Map component identifier to Aeon ItemCallNumber field; and (6) ability to pull the "conditions governing access" note. This will help staff process requests that are created in the Aeon client using the ASpace addon.
-
Valerie A commented
U Baltimore - Langsdale requested
Container/Volume: just the box number here, please; NOT all of the location information
Subcontainer /Copy: just the folder number here
Resource ID: We would like this field to contain the item’s call number (with is id_0-Id_3 and not EAD ID)
Additional Location: all of the location information that currently follows the box/folder number in the Container/Volume field . This is most likely referring to the current behavior of the addon, where top container and location information all get added to one field. This (and many sites) want just the top container to go into one field (usually Aeon ItemVolume) and the [rest of] the location info to go into a different field, usually either the main Aeon location field or the SubLocation field. -
Anne Marie Lyons commented
UC Santa Barbara would like for the Resource Identifier of the ASpace resource record to write to the Aeon CallNumber field instead of the EADID that is currently writing to the CallNumber field.
-
Anne Marie Lyons commented
The University of Baltimore and UC San Diego would like for the "ArchivalObjectInstance" that currently writes to the ItemVolume field to not include repetitive information. It includes the collection name and location information (both repetitive - that information already writes to other fields as part of the import), along with the top container type and indicator, which is the only information needed in this field. Baltimore would also like the ability to have the location information write to the SubLocation field instead.
-
Zachary Liebhaber commented
UCSB would like to import the location information associated with the requested top container record into the Aeon Location field.
-
Anne Marie Lyons commented
The University of Pittsburgh would also like the ability to import the child and grandchild instance information.
-
Penny White commented
UVA would also like to see the collection number in the CallNumber field over the container string, which for us includes item locations when available. This information gets lost/is not easily identifiable amidst the container string.
Mapping the location field to ItemSubLocation +1
-
Anne Marie Lyons commented
The University of Pittsburgh would also like to import an indication when the "Restrictions Apply?" checkbox is checked. The checkbox is located in the Basic Information section of the resource record at both the collection level and the component level.
-
Anne Marie Lyons commented
The University of Southern California would like the following mapping customizations to be available in the addon:
· No author or barcode info would be imported into the request. Barcode is currently included in the container string that maps to the ItemVolume field.
· ItemVolume would only get the specific box information; for example, “Box 6," instead of the lengthy string of additional fields that is currenlty importing
· The collection number should import into the CallNumber field . Right now, the collection number is only included in the container string.
· The location information should map to the ItemSubLocation field instead of the Location field.