<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div><br></div><div>Initially, we were hoping we could do a batch import of our 4000+ EAD finding aids into ArchivesSpace</div><div>and use it to clean up the guides to a better level of consistency and standardization, and avoid staff</div><div>having to deal with editing and validating XML. However, we ran into the problem that ArchivesSpace</div><div>requirements for EAD import are stricter than the EAD schema, and the guides need to be cleaned up</div><div>AS xml first before importing. </div><div><br></div><div>Our first attempt was to try to automate some of this with an XSL stylesheet that tried to coerce our EAD</div><div>into conformance with what ArchivesSpace’s import expected. With this preprocessing, we were able</div><div>to ingest the majority of our EAD guides. </div><div><br></div><div>A lot of our EAD had <physdesc> with no <extent> elements, or else extent did not conform to ( number,unit )</div><div>required by ArchivesSpace, so our stylesheet either wrapped the physdesc/text in an extent element </div><div>( it it started with a digit and looked like it might be a ( number, unit ) ) or inserted: '<extent>1 arbitrary_unit</extent>’</div><div><br></div><div>Unfortunately, this had the side effect of exploding the controlled value list for extent_extent_type and making </div><div>the drop down menu for that field unusable as there were too many values to display. </div><div><br></div><div>We were giving up the idea of importing them all in a batch and planning on setting up our test server </div><div>as a staging server. We would import and clean up EAD on the test server before exporting and re-importing</div><div>on the production server. Importing them all in one batch made it too difficult to clean up and merge </div><div>extents in the controlled value list. There was still a problem with flagging all of the extents that needed</div><div>manual review. The ‘1 arbitrary_unit’ was easy to find, but the others were more of a problem. </div><div><br></div><div>( We also had issues with required unitdate | unittitle , empty elements, and other differences in imput mappings </div><div> that we attempted to fix with our stylesheet. ) </div><div><br></div><div>I have since found another method. I have modified the resource schema to make extents and dates not required,</div><div>and added it to plugins/local/schemas: <a href="https://github.com/uvalib-dcs/ASpace-plugins/tree/master/schemas">ASpace-plugins/schemas at master · uvalib-dcs/ASpace-plugins</a></div><div><br></div><div>We may try a combined approach: doing some fixup with XSL stylesheet, but not trying to coerce everything</div><div>into an extent, and doing a lot more manual review. And importing in smaller batches to avoid massive namespace</div><div>pollution and cleaning up as we go along. </div><div><br></div><div>If we keep the tighter requirements on the production server, we will obviously discover missing dates and extents</div><div>on that 2nd import, but we would prefer to be able to catch and flag these earlier. Is there a way to use the looser,</div><div>modified schema on import and require a tighter schema on publishing or export ? </div><div><br></div><div>I would also be interested to hear of others experience with these issues or ideas for dealing with them. </div><div><br></div><div>— Steve Majewski / UVA Alderman Library</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></body></html>