...
Time | Item | Who | Notes | ||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Roll Call | Noah |
| |||||||||
5min | Roundup of migration support work | Noah/all | Review / summarize recent requests for migration support:
| ||||||||
5 min | Prioritizing JIRA issues in import / export epic? | Brad? | Update on work of Features Prioritization team? Update from Brad:
| ||||||||
5min | Changes to EAD importer re: publish/unpublish behavior | Noah | Review recent changes to EAD importer:
Brad identified a potential issue where the default import behavior might be in conflict with the globally set preferences re: publication status. Noah and Brian agreed to test this (see action item below). | ||||||||
5min | Schematron testing | Noah/Brian/Terry | Review schematron testing, next steps?
| ||||||||
15min | EAD3 Support | Terry/Noah | More thoughts on timeline, strategy, next steps? Placeholder JIRA issue for EAD3 support:
See Alex Duryee's EAD2002 to EAD3 transformation walkthrough:
Some comments from Mike Rush on EAD3 support in Aspace (from email conversation with Noah): I do think that a basic EAD3 export profile could be put together given the current ASpace data model, but there are a few areas that will require changes to the data model for full EAD3 support. The most obvious will be extents. The <physdescstructured> model is much more expressive than what ASpace does, and in what I think are important ways that ASpace should reflect. The "finding aid data" section that corresponds to the EAD 2002 eadheader will need extensive updates to comply with the <control> model as well. Might need some tweaks around <langmaterial>. <legalstatus> will need to be added as a full <did> sibling. And a decision will need to be made whether to support <relations> or not. Off the top of my head that's probably the biggest areas that would impact the ASpace data model. There might be other places here and there where ASpace would need to decide to accept things like <descriptivenote> or not, but as long as the import/export profile is documented well (preferably in Schematron) it would't be a big deal. I'm sure I'm missing something, but ASpace already avoided so much of the EAD weirdness that the revision attempted to address that few drastic changes will be necessary. Possible strategy and next step:
NOTES ON DISCUSSION:
| ||||||||
5min | Other announcements/updates? | All | Michael V. updated group on progress with Harvard's EAD import project. Out of ~6,000 EADs, about 5,000 have been imported. Using the ASpace JSON model plugin?, Harvard has developed a process for converting EAD to JSON and posting to ASpace using the API. Michael may describe this process to the group in a future meeting. |
...