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-boun...@lyralists.lyrasis.org
[mailto:archivesspace_users_group-boun...@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@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
_______________________________________________
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
