2016-09-15 Meeting notes

Matt Gorzalski no longer on group, Phil Suda and Terry Reese's status uknown.

Dave Mayo joins group as "affiliate" member

What tools, methods, workflows, processes might be generalizable to other institutions? What info is publicly available? Where is it?

Some links:

• EADChecker - one-off app for checking EAD: https://github.com/harvard-library/archivesspace-checker
  • Harvard web app: https://eadchecker.lib.harvard.edu/
  • Can upload EADs individually to above webapp
    
    
• Preprocessor - app for doing bulk processing of EADs and tracking changes made: https://github.com/harvard-library/archivesspace-preprocessor
  • Stores info about changes in a local database

• Fixes and test-cases for the above preprocessor:https://github.com/harvard-library/aspace-processor-fixes
  
  

• Bulk ingest script using API, analysis script for output from bulk ingest script: https://github.com/harvard-library/aspace-utils
  • Allows batch ingest by posting json to backend API
  • Batch ingests will not fail if one file fails (unlike native EAD import tool)

• Gem for running Schematron over XML files: https://github.com/harvard-library/schematronium

NOTES:

--Dave walked through the tools above and described how they're used in Harvard context.

--Noted that ArchivesSpace version 1.5.2 should include faster EAD import times (can run more than one import simultaneously)

--Dave mentioned a few institutions have contacted him for info on using the tools (NYU, Princeton Theological)

--If/When ArchivesSpace github is reorganized all of the tools above will be good candidates for new archivesspace-labs organization

--Given current lack of ASpace developer resources, it probably doesn't make sense to pursue integration of these tools into core application at this time

What can we borrow from this process to inform EAD3 Spec development work?

ASpace / EAC spec?: https://docs.google.com/spreadsheets/d/18Ddra_mYeRYUQR9pTH_OsR5A_NQoVEBuyz-1EfA5RVc/edit?usp=sharing

NOTES

--Cory mentioned that Brad is probably in best position to comment on required documentation.

--Cory noted that this work was byproduct of BYU feature requests for improved support for structured date subrecords and relations.

Goal is to outline a process for developing a spec for EAD3 support (import/export).

Qs:

1. What documentation is needed.
2. What form should it take?
3. Who should participate outside of this group?

Hopefully we can develop a list of tasks and assign responsibility to those tasks.

NOTES:

• Cory mentioned the tension between supporting structured vs. unstructured content in ASpace given that EAD3 can accommodate both
• Terry C. suggested that ASpace should focus on importing structured content from EAD3 (when deciding between structured vs. unstructured in areas like dates). The group agreed--this is the real utility of database applications like ASpace.
• Terry C. noted that the EAD2002toEAD3 XSLT stylesheets already provide a way to generate EAD3 from ASpace and so the group should focus on imports, particularly on areas that require data model changes (structured elements, and possibly relations). In other areas, the EAD3 import spec should not be that complicated.
• Terry C. noted that presumably ASpace already handles other areas like <control> for EAC-CPF exports. This model/code could be borrowed for EAD3.
• The group discussed issues with the EAD2002 to EAD3 stylesheets and Terry clarified some things:
  • For testing purposes, should not use "undeprecated" version of the XSLT as this preserves deprecated elements in the EAD3 output.
  • Use of the RNG and XSD versions of the schema are preferred over the DTD because they include more constraints. RNG is preferable, but can't be embedded in other schemas like XSD
  • Noah mentioned experiments at Duke transforming ASpace EAD output to EAD3. Will send output files to Terry for review.
• Even though users could derive EAD3 from ASpace using the existing migration XSLT files, there is still a desire to support native EAD3 round-tripping as much as possible keeping in mind that loss-less round-tripping may be a pipe dream. Still, importing and exporting EAD is an important part of the descriptive workflow for many institutions (Duke included).
• Noah suggested a next step would be to create a Google Sheet based on the current EAD2002 to ASpace mapping document: http://www.archivesspace.org/sites/default/files/EAD-Import-Export-Mapping-20130831.xlsx
  • The group can begin by collaboratively updating the import mappings for EAD3, paying particular attention to areas that might require data model changes
  • We will reach out to others who might be interested in participating in this work: Mike Rush, Mark Custer, EAD roundtable members? (Alex D., Ruth Tillman?)
  • The end result will be a specification that can be handed over to ASpace developers (when there are ASpace developers...)
  • Will follow up with Brad for feedback on this strategy