[Archivesspace_Users_Group] EAD import extents mapping

[Custer, Mark]

John,

What I think that you'd want to do in this case is to modify the EAD so that it looks like the following:

<physdesc label="Extent:" encodinganalog="300">
<extent>15.0 linear_feet</extent>
<extent>(36 boxes + oversize folder)</extent>
</physdesc>

Two important points about this:


  1.  The ASpace EAD importer uses the database values for controlled value fields, which is why I've changed linear feet to "linear_feet"  ("linear_feet" is one of the database values available in ASpace by default, but if that's not the value that matches your YML translation, you might want to use another one).  The ASpace EAD exporter, on the other hand, will use the YML translation when exporting the EAD, so you'd wind up with "linear feet" in the export, or whatever else is specified in the YML file that's being employed by your application.
  2.  Whatever you put into a second extent statement will be mapped to the Container Summary field in ArchivesSpace.

This is essentially following the AT model for importing EAD physdesc elements.  I wish, instead, that ASpace would only add extent values based on the availability of the extent/@unit attribute in EAD 2002.   That would make things a lot less dicey than trying to  parse the text field of an extent element during import time, but it would require more EAD manipulation for a lot of folks before importing that data since the @unit attribute isn't heavily used.

Mark

p.s.   the physdesc/@label attribute, however, does NOT get mapped at all by ASpace.  Instead, it's dropped silently during the import process.  That used to be the case, at least.  I haven't checked in a while to see if that behavior has been changed, but in general label attributes and head elements will usually map to the ASpace label field.

p.p.s. I've never tested to see what happens if you have a third sibling extent statement (to see if those get dropped or appended to container summary).  But I have tested using dimensions and/or physfacet within the same grouping, and those are imported as expected.




From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Rees, John (NIH/NLM) [E]
Sent: Thursday, 21 June, 2018 3:43 PM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org>
Subject: [Archivesspace_Users_Group] EAD import extents mapping

Using the background job importer, I'm trying to import extent data from EAD 2002 schema XML, specifically the other extent data we record in parenthesis like <physdesc label="Extent:" encodinganalog="300"> <extent>15.0 linear feet (36 boxes + oversize folder)</extent> </physdesc>

I'd like these parenthetical statements to map to the Container Summary field. According to the EAD import mapper http://archivesspace.org/wp-content/uploads/2016/05/EAD-Import-Export-Mapping-20171030.xlsx<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Farchivesspace.org%2Fwp-content%2Fuploads%2F2016%2F05%2FEAD-Import-Export-Mapping-20171030.xlsx&data=02%7C01%7Cmark.custer%40yale.edu%7C7fd7312237a74499772f08d5d7af3fb7%7Cdd8cbebb21394df8b4114e3e87abeb5c%7C0%7C1%7C636652070056478978&sdata=pB8JYJlx5gpDPD8ugiqZReY2BLk60%2BkfTaOHex%2B0EEU%3D&reserved=0> anything after a number and space that can't be parsed should import into Container Summary.

Is there a syntax for making this string unparsable and force this behavior? Currently "linear feet (36 boxes + oversize folder)" from the above imports to Extent @Type as a new unique value and I don't want all that data pollution.

Thanks,
John

John P. Rees
Archivist and Digital Resources Manager
History of Medicine Division
National Library of Medicine
301-827-4510


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180622/ed4fc964/attachment.html>