| Time | Item | Who | Notes |
|---|
| Roll Call / introduce special guests | |
|
| 5min | Quick overview of past/ongoing Migration sub-team work | |
|
| 10min | Overview of ongoing HM development work, roadmap? | | - HM contracted until end of June
- Committed to minor release in December and two major releases (March, June)
- Hope that June release will include some major new features (possibly rights management and reporting, but still TBD)
- Hope to have development roadmap by end of 2016
|
| 30min | Discuss EAD3 support in ArchivesSpace | All | - EAD support for ASpace is a TS-EAS priority for 2016-2017
- Reviewed prior conversations in this group about EAD3 support (for non-members on call)
- 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
|
| 5min | Document next steps, timeline, action items for EAD3 support | All |
|