--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
15min
Overview of EAC-CPF spec development process
Cory/Brad?
What can we borrow from this process to inform EAD3 Spec development work?
--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.
20min
Establish process for developing EAD3 Spec
Noah/all
Goal is to outline a process for developing a spec for EAD3 support (import/export).
Qs:
What documentation is needed.
What form should it take?
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 support both
Terry C. suggested that ASpace should focus on importing structured content from EAD3 (when deciding between structured vs. unstructured). The group agreed--this is the 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
Even though users could derive EAD3 from ASpace using the existing XSLT, 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, it's an important part of the descriptive workflow for many institutions (Duke included).