10min | Overview of ongoing HM development work, roadmap? | | - Discuss ongoing HM development priorities
- What is capacity, process for new feature requests?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 | Discuss - EAD support for ASpace is a TS-EAS
priorities EAD3Review - Reviewed prior conversations in this group about EAD3 support (for
nonmembers Get feedback from James on how to develop EAD3 import spec, next steps Possible spec format options:
- 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.
How to organize work? Assign resposibility for EAD3 sections? (e.g. control, archdesc/did, notes, controlaccess, dsc)- 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
|