- Discussed and revised Guiding Principles for EAD3 support in ArchivesSpace (DRAFT): https://docs.google.com/document/d/1flWS83CRDvdc2cG8pWYA7bqRTckj9yJc3ucMBgLz8qE/edit?usp=sharing
- 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:
- Decision to use basic EAC>Aspace model: https://docs.google.com/spreadsheets/d/18Ddra_mYeRYUQR9pTH_OsR5A_NQoVEBuyz-1EfA5RVc/edit?usp=sharing
- 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
|