2016-06-10 Meeting notes

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

Date

10 Jun 2016 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

Time	Item	Who	Notes
	Roll Call	Noah	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
5min	Roundup of migration support work	Noah/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 min	Prioritizing 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.
5min	Changes to EAD importer re: publish/unpublish behavior	Noah	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).
5min	Schematron testing	Noah/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
15min	EAD3 Support	Terry/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: https://github.com/saa-ead-roundtable/EAD-2002-to-EAD3-transformations/tree/master/nypl-ead2002-to-ead3 Commit Log: https://github.com/saa-ead-roundtable/EAD-2002-to-EAD3-transformations/commits/master 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.
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.

Action items

Noah Huffman 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 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.