Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 15 Next »

Rescheduled from 5/13/2016 to 6/10/2016

Date

at 1pm, ET

Call Info:

1-888-354-0094

Access code is 731627

Attendees

Goals

  • Reviewing status of ongoing work

Discussion items

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: AR-923 - Getting issue details... STATUS

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 existing "ArchivesSpace to EAD" mappings into new sheet and update with EAD3 mappings (maybe make this a GoogleSheet for collaborative editing/commenting?)
    • 3) Group to review new mappings, identify areas where current data model doesn't support EAD3
    • 4) Decide if data model changes are necessary; seek community feedback
    • 5) 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 

Action items

  •  
  • No labels