2016-06-10 Meeting notes

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

Date

at 1pm, ET

Call Info:

1-888-354-0094

Access code is 731627

Attendees

Absent:

  • Terry Reese
  • Chris Prom
  • Cory Nimer
  • Phil Suda
  • Brian Hoffman

Goals

  • Reviewing status of ongoing work, brainstorm strategy/next steps for EAD3 support

Discussion items

TimeItemWhoNotes
Roll CallNoah
  • Not sure if Phil Suda intends to stay on group since taking a new position.
  • Matt Gorzalski may rotate off of group at end of June
5minRoundup of migration support workNoah/all

Review / summarize recent requests for migration support:

  • Provided migration consultations to Smithsonian (AT), WVU (EAD, other legacy systems), and Athens Co (Ga.) Library (MS Access)
  • Requests were forwarded from Christine and Brad to Noah. In the future, Noah will cc other members of the sub-team on responses
  • Brian Harrington (Lyrasis) has experience providing migration support and is willing to assist
5 minPrioritizing JIRA issues in import / export epic?Brad?

Update on work of Features Prioritization team?

Update from Brad:

  • Features Prioritization team is reviewing JIRA issues in Import and Export epics
  • Will eliminate/merge duplicate issues, delete issues that are no longer necessary, and identify any issues that need further specification or explanation
  • Migration Sub-team might be called on to provide further specification on import / export issues
  • There are plans to prioritize stories within each epic
  • There will be another round of voting by member reps, probably at the Epic level.
5minChanges to EAD importer re: publish/unpublish behaviorNoah

Review recent changes to EAD importer:

  • Mark's pull request: https://github.com/archivesspace/archivesspace/commit/b3e96570fa9d0128b2424c86a36f2926bff9099c
  • JIRA Issue re: importing finding aid status values in <eadheader>: AR-1282 - Getting issue details... STATUS
  • Mark's pull request makes the following changes to EAD import behavior:
    • publishes all components, notes, and subnotes by default on import unless audience attribute set to "internal"
    • sets resource records to unpublished by defaul unless collection level audience attribute set to "external"
    • better handling of single dates on import

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).

5minSchematron testingNoah/Brian/Terry

Review schematron testing, next steps?

  • Noah did some testing and forwarded some issues to Terry. Terry is on leave, but will pick up this work when he returns, mid-July?
  • Michael V. will ask if Dave Mayo's schematron has been updated since he provided it to Terry. See Terry's consolidated schematron rules at: https://github.com/tcatapano/EAD_Archivespace_Import
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 (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:

  • 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?

NOTES ON DISCUSSION:

  • Noah proposed above plan to focus first on getting ASpace to support EAD3 exports using the current ASpace data model. EAD3 exports would be valid, but using the current ASpace data model means we couldn't take full advantage of EAD3's expressiveness, especially in areas like <physdescstructured>, <relation>, etc.
  • Brad suggested thinking about imports first and identifying what changes might be necessary in ArchivesSpace to import full range of EAD3 elements
  • Brad indicated that some preliminary spec work has already been done with EAC that might inform the work above.
  • Brad thinks that EAD3-related data model changes to ASpace should be minor (unlike the data model changes required to support container management).
  • Brian Harrington noted that institutions often ask about EAD3 support when deciding whether or not to become ArchivesSpace members. While it's probably just a checklist item, it seems relatively important to the community.
  • The group wondered about how eager the community is to implement EAD3 and agreed that ArchivesSpace will probably play a major role in EAD3 adoption.
  • ArchivesSpace will still need to support for EAD2002 for some (probably lengthy) period of time, but the level of support could wither.
  • The group identified some folks that might help with this work–Mike Rush, Alex Duryee, EAD Roundtable members. Noah will follow up to see what kind of help might be available. In particular, if anyone has time and expertise to write a basic EAD3 export plugin using an updated ASpace to EAD3 mapping document.
  • Noah suggested it would be nice to have a rough idea of an EAD3 support work plan and timeline to communicate at SAA in early August. It'd also be nice to have a basic EAD3 export plugin to demo as a proof of concept. Is this too ambitious?
  • We will continue this discussion when Terry C. and others can participate.
5minOther announcements/updates?AllMichael 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.

Action items

  • Noah Huffman (Deactivated) to copy sub-team members on any future requests for migration support (received from Brad or Christine)
  • All: Work with Features Prioritization, as needed, to provide further specification of JIRA issues in Import or Export epics
  • Brian Harrington (Unlicensed) and Noah Huffman (Deactivated) will test changes to EAD import behavior and identify if there is conflict with default unpublish/publish behavior and any globally set preferences.  Will update JIRA issue with results of testing (and notify Mark if there is a problem).
  • Michael Vandermillen (Unlicensed) will ask Dave Mayo if Harvard has added any additional schematron validation rules since he provided the initial schematron to Terry.