Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

TimeItemWhoNotes
Roll CallNoah 
5minRoundup of migration support workNoah/allReview / summarize recent requests for migration support and responses
5 minPrioritizing tickets in import / export epic?Brad?Update on work of Features Prioritization team?
5minChanges to EAD importer re: publish/unpublish behaviorNoah

Review recent changes to EAD importer:

 

5minSchematron testingNoah/Brian/Terry

Review schematron testing, next steps?

15minEAD3 SupportTerry/Noah

More thoughts on timeline, strategy, next steps?

Placeholder JIRA issue for EAD3 support:

Jira Legacy
serverJIRA (archivesspace.atlassian.net)
serverId36c489e2-4fb0-353a-985b-64038401be2f
keyAR-923

See Alex Duryee's EAD2002 to EAD3 transformation walkthrough:

Some comments from Mike Rush on EAD3 support in Aspace:

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:

  • Modify EAD Import/Export mapping doc at: http://www.archivesspace.org/importexport
    • 1) Add a sheet for "ArchivesSpace to EAD3,"
    • 2) Copy ArchivesSpace to EAD" mappings into new sheet and update with EAD3 mappings (maybe make this a GoogleSheet for collaborative editing)
    • 3) Group to review
    • 4) Group to submit formal feature request for adding EAD3 export support with current data model OR take a stab at modifying the EAD exporter as a plugin?
5minOther announcements/updates?All 

...