After discussion, group decided to prioritize support for EAD3 exports in ASpace.
Rationale: There are very few examples of native EAD3 and getting tools to support creation of EAD3 should be our first priority.
ASpace should be able to consume any EAD3 that it exports, but not necessarily all valid EAD3
Discussed some special considerations for supporting EAD3 in ASpace:
Dave and Mark stressed that we should be mindful of mixed content
ASpace's current flexibility with mixed content may be incompatible with EAD3
We should think carefully about implications for continued support for mixed content
Cory advocated for adding support for recording URIs throughout the application (e.g. for controlled vocabularies, etc.)
Mark noted current problems with storing namespace values as mixed content (ns:2, xlink, etc.). It would be nice to have a convenient way to locate and clean up these values, which are incompatible with EAD3.
Discussed possible ways to format an EAD3 spec for ASpace:
But, instead of representing entire EAD3 element set in new spec, we should start with only those areas of significant departure from EAD2002, particularly structured elements
According to Mike Rush, we should begin developing spec for these areas: <control>, <physdescstructured>, <unitdatestructured>, <langmaterial>, <relations>.
Also include container IDs.
Noah will begin a document (Google Sheet) with the areas above and circulate. Group members are encouraged to contribute to one of the areas. We will check in on progress on our next call
5min
Document next steps, timeline, action items for EAD3 support
All
Action items
Noah Huffman - revise EAD3 support guiding principles doc, circulate
Noah Huffman - create Google Sheet for working on EAD3 spec and circulate; prioritize structured EAD3 elements (control, langmaterial, unitdatestructured, physdescstructured)
Noah Huffman - Send Doodle Poll for next meeting, probably early-mid January after holidays?