Re: [Archivesspace_Users_Group] EAD import extents mapping
Thanks Mark. Luckily we only use one statement and the syntax is
pretty uniform across our corpus.
Today I discovered a 2nd sans will also import nicely into
a Physical Description Note. This note exports as a vanilla but your
approach produces more specific and parsable EAD for down the road.
And yes, I've been tracking the silent label drops esp. since our external
public access application often depends on them.
John
From: Custer, Mark [mailto:mark.cus...@yale.edu]
Sent: Friday, June 22, 2018 8:59 AM
To: Archivesspace Users Group
Subject: Re: [Archivesspace_Users_Group] EAD import extents mapping
John,
And it case it helps, here's the admittedly hacky way that I've handled this in
the past, only focusing on splitting out those linear footage statements since
that's what we had to deal with:
I should note, though, that our incoming EAD files would only have a single
extent statement to begin with, so I wouldn't use this without inspecting
another EAD corpus before running it there. But for the example that you
originally provided, it should do the trick. Just be careful if those
statements aren't uniform in your corpus, since the above template really only
expects physdesc elements with a single extent child.
Mark
From:
archivesspace_users_group-boun...@lyralists.lyrasis.org<mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>
[mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org] On Behalf Of
Custer, Mark
Sent: Friday, 22 June, 2018 8:50 AM
To: Archivesspace Users Group
mailto:archivesspace_users_group@lyralists.lyrasis.org>>
Subject: Re: [Archivesspace_Users_Group] EAD import extents mapping
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:
15.0 linear_feet
(36 boxes + oversize folder)
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>
[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
mailto: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 15.0 linear feet
(36 boxes + oversize folder)
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
Re: [Archivesspace_Users_Group] EAD import extents mapping
John,
And it case it helps, here's the admittedly hacky way that I've handled this in
the past, only focusing on splitting out those linear footage statements since
that's what we had to deal with:
I should note, though, that our incoming EAD files would only have a single
extent statement to begin with, so I wouldn't use this without inspecting
another EAD corpus before running it there. But for the example that you
originally provided, it should do the trick. Just be careful if those
statements aren't uniform in your corpus, since the above template really only
expects physdesc elements with a single extent child.
Mark
From: archivesspace_users_group-boun...@lyralists.lyrasis.org
[mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org] On Behalf Of
Custer, Mark
Sent: Friday, 22 June, 2018 8:50 AM
To: Archivesspace Users Group
Subject: Re: [Archivesspace_Users_Group] EAD import extents mapping
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:
15.0 linear_feet
(36 boxes + oversize folder)
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>
[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
mailto: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 15.0 linear feet
(36 boxes + oversize folder)
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=02%7C01%7Cmark.custer%40yale.edu%7C7fd7312237a74499772f08d5d7af3fb7%7Cdd8cbebb21394df8b4114e3e87abeb5c%7C0%7C1%7C636652070056478978=pB8JYJlx5gpDPD8ugiqZReY2BLk60%2BkfTaOHex%2B0EEU%3D=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
Re: [Archivesspace_Users_Group] EAD import extents mapping
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:
15.0 linear_feet
(36 boxes + oversize folder)
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
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 15.0 linear feet
(36 boxes + oversize folder)
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
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
