Multi-field identifiers in MARC XML and EAD imports

10 views
Skip to first unread message

Russell, Elizabeth

unread,
Jun 18, 2024, 5:34:17 PMJun 18
to archivesspac...@lyrasislists.org

We use two of the resource record identifier fields. Is it possible to deal with this in a MARC XML upload or EAD upload without customizing the batch job process or doing post-import data clean-up? I can’t find any way of getting ASpace to import data into more than one identifier field.

 

Thanks,

 

Elizabeth

 

Elizabeth Russell

Senior Archivist

Providence Archives

4800 37th Ave. S.W.

Seattle, WA 98126-2793

(206) 923-4011

elizabet...@providence.org

providence.org/archives | sistersofprovidence.net

 

 

 

 




This message is intended for the sole use of the addressee, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the addressee you are hereby notified that you may not use, copy, disclose, or distribute to anyone the message or any information contained in the message. If you have received this message in error, please immediately advise the sender by reply email and delete this message.

Russell, Elizabeth

unread,
Jun 27, 2024, 4:19:08 PM (5 days ago) Jun 27
to archivesspac...@lyrasislists.org

Hi everyone,

 

Since ASpace MARC and EAD imports/exports can only use one resource ID field, I’m wondering if institutions that use multi-field IDs for resource records have come up with any workaround to enable them to still use MARC and EAD imports/exports. Aside from this specific question, I’m wondering whether folks think it is actually better to stick with using only one of the resource record ID fields anyway. I’ve heard from our hosting vendor that it simplifies API calls. Any strong opinions on this out there?

 

Thanks so much,

 

Elizabeth

 

Elizabeth Russell

Senior Archivist

Providence Archives

4800 37th Ave. S.W.

Seattle, WA 98126-2793

(206) 923-4011

elizabet...@providence.org

providence.org/archives | sistersofprovidence.net

 

 

Dan Michelson

unread,
Jun 27, 2024, 4:27:16 PM (5 days ago) Jun 27
to Russell, Elizabeth, archivesspac...@lyrasislists.org
Hi Elizabeth,

I can't say I do much export of MARC or EAD these days, but we use multi-field IDs for identifiers and have not noticed any issue with them appearing correctly in exports.

All the best,

Dan

--
You received this message because you are subscribed to the Google Groups "Archivesspace_Users_Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to Archivesspace_User...@lyrasislists.org.
To view this discussion on the web visit https://groups.google.com/a/lyrasislists.org/d/msgid/Archivesspace_Users_Group/CO1PR04MB8236C445C08CC6DB91195C7D99D72%40CO1PR04MB8236.namprd04.prod.outlook.com.


--
Dan Michelson
Collections Archivist
Smith College Special Collections

Russell, Elizabeth

unread,
Jun 27, 2024, 4:37:58 PM (5 days ago) Jun 27
to Dan Michelson, archivesspac...@lyrasislists.org

Hi Dan,

 

Thanks for the reply. What version of ASpace are you running? We are still on 3.3.

 

The behavior we experience with exports is that ASpace takes a multi-field ID and combines into a number with a period in between the two parts in the MARC or EAD record. Since we format our numbers with a hyphen in between parts, that will create some consistency issues for us.

 

However, the bigger issue for me right now is that I’m planning a large import project. I’d like to use MARC XML to import collection level descriptions, but I’ve heard from Lyrasis staff that ASpace currently can’t take a MARC record and import the different parts of an ID into the correct “field 1,” “field 2,” etc. So I’m thinking of scrapping multi-field IDs for resource records and expressing the whole number in one field. We use a 2-field identifier for our accessions, but it isn’t a problem since we were able to use the CSV import for our migration on those.

 

-Elizabeth

Dan Michelson

unread,
Jun 27, 2024, 5:11:53 PM (5 days ago) Jun 27
to Russell, Elizabeth, Archivesspace_Users_Group
3.5.0, but the export does still use periods instead of dashes (might be worth submitting a JIRA ticket about that, can't think of any reason it should be different in the exporter than in the PUI).

While we use the multi-field IDs, I'm struggling to think of any benefit we get other than a somewhat reduced chance of data entry errors. If we had a need to routinely import MARC or EAD, I'd probably just change to using the first identifier field.

The only time we did a large scale MARC import since I've been here we used a Python script to do a custom mapping because our data was so weird (and I had a staff member who could do it for me).

Dan

Joshua D. Shaw

unread,
Jun 27, 2024, 5:13:48 PM (5 days ago) Jun 27
to Archivesspac...@lyrasislists.org
Yep. Out of the box, AS will munge the id fields together on export. And on import it'll just populate id_0 since it really doesn't have any way to express delimiters to split on.

You can​ modify those behaviors with a plugin, but that's extra dev time - if you even have that capacity.

One potential solution for the import would be to run a post-import update - either via the API or with a direct db update (API is much​ preferred!). This might be more time effective if this is a one (or very few) import batches type scenario.

For export, you could also post-process the XML with an XSLT. But, that could get tedious.... 

If its helpful, here's an example of an export modifying plugin: https://github.com/hudmol/dartmouth_udf_exports That version is a bit out of date, but if you're interested I can pop up our current version that we've modified for later versions of AS.

Best,
Joshua


From: 'Russell, Elizabeth' via Archivesspace_Users_Group <Archivesspac...@lyrasislists.org>
Sent: Thursday, June 27, 2024 4:37 PM
To: Dan Michelson <dmich...@smith.edu>
Cc: archivesspac...@lyrasislists.org <archivesspac...@lyrasislists.org>
Subject: RE: [EXTERNAL] Re: [ArchivesSpace Users Group] RE: Multi-field identifiers in MARC XML and EAD imports
 
Reply all
Reply to author
Forward
0 new messages