2019-10-02 Meeting Notes

Date and Time

Oct 2, 2019

09:00PDT/12:00 EDT - 10:00PDT/13:00 EDT

Zoom URL

https://lyrasis.zoom.us/j/897871318

Participants

• @Kevin Schlottmann

• @James Griffin (Unlicensed) (Note taker)

• @Daniel Michelson

• @Maggie Hughes

• @Dallas Pillen

• @Wiedeman, Gregory

• @Christine Di Bella

• Bria Lynn Parker

Goals

• Introductions for Participants

• Work Plan

Discussion topics

Action items

Notes

(Introductions were held)

Overview of the Sub-team

• We are tasked to come up with a work plan and activities which can be reasonably executed over the next year

• We should hone in by the end on a rough work plan and begin scheduling

• Moving ArchivesSpace to support the identified metadata standards

Reviewing the Sub-team Charge

• https://archivesspace.atlassian.net/wiki/spaces/AC/pages/880246813

• Note that we might need to prioritize different parts of the charge

  • We also might not get to every item of the charge

  • This charge can be edited throughout the year

• Around ArchivesSpace, addressing metadata standards was seen as a real need

• This charge seems to ensure that this need is going to be addressed

Metadata Standards

• Migration is often heavily informed by ensuring that the imported metadata follows standardized schema

  • How can we make explicit what ArchivesSpace commits to in terms of metadata standards?

  • How do we document this?

• Daniel: A lot of this works came out of the structure of the EAD

  • There is a desire to ensure that EAC-CPF and MARC exports are fully supported from within ASpace

  • Tooltips for the system are based on DACS, but this is customizable

  • Resource record section is based on EAD and DACS

• Internationalization

  • We should note that RAD or ISAD might be preferred by adopters outside of the United States

  • Hence, DACS might not be preferred for those outside of the US

• OAI-PMH Implementation

  • Note that this supports Dublin Core

• There are tiers of support for standards when it comes to adherence

  • For some standards, ASpace just exports data with the bare minimum level of compliance

  • This should be distinguished

  • Highest level of compliance and documentation should be there for MARC, but for cases such as Dublin Core, we might just offer the mapping

  • Daniel: EAD adherence is really the highest tier

  • Greg: Defining these tiers and standards can be a work plan item

  • Kevin: MARC is constantly considered at Columbia University, a robust MARC implementation within ASpace would be ideal

  • Greg: We should explore how DACS applies to ASpace, documenting how it is implemented would be valuable

• Kevin: We should look towards documenting existing import and export mappings for at least EAD and MARC, and get these up to date

  • These are behind by more than one year

  • Bria: In the Migrations Sub-group, having a path for getting these mappings updated would have been valuable

  • Greg: Ensuring that communicating that a certain element must be updated in the mapping alone would be a great contribution

  • Kevin: This would likely be offered as instructions to community members in how to create JIRA tickets for review

Documentation

• Christine: Much of the ASpace documentation is being migrated to Confluence, hence it might be best to explore migrating this mapping documentation here as well

  • Kevin: To what extent could some of this process involve documentation generated from the code base?

  • Christine: This is difficult to determine, but when changes are made to the API, there can be documentation updates which are generated

    • Not certain as to whether or not this could be supported for export/import functionality

  • Note that Data mapping is not a part of the technical documentation

  • There are a few spreadsheets which are linked from the general documentation

  • Christine: The technical documentation focuses upon what is involved in installing and deploying the application

  • There has not been a full effort to update the MARC export/import maps due to limited developer resources

MARC Mapping Concerns

• Migrations Working Group found that there are some long-standing, complex issues regarding the importation of more obscure MARC fields

• It would be best to try and break this down into actionable tasks

• Kevin: Some of the behavior might be adjusted within the JRuby code base

• Adjusting the field-level mappings for MARC export/imports can perhaps be demonstrated or documented for the community

• Christine: This group should decide what the way is regarding the default/”one true way” to support default mappings

Support for Emerging Standards

• There should also be an understanding that the standards are vast, and that there might be a need to call on expertise from outside of the community

• Controlled vocabularies might be an area where catalogers would be preferred in terms of inviting colleagues to collaborate

• EAD3 is still also a fairly new standard, and expertise might need to be invited

• RIC is another standard which should be considered

• https://www.ica.org/en/records-in-contexts-ric-a-standard-for-archival-description-presentation-congress-2016

• Exploring how difficult it might be to support Records in Context would be desirable as well

• TS-DACS membership ensures that we have parties who are engaged in the development and finalization of this standard

  • Perhaps we should consider a call to the general Technical Advisory Committee enquiring about DACS support once work with the DACS progresses

Work Plan Tasks and Goals

• Defining our level of commitment to various standards

• Addressing various mappings (this will need to be broken down into tasks, and we will need to ensure that we clearly define our level of commitment)

• How DACS integration is supported and how tooltips are in sync.

• Addressing dev. tickets and to what extent a request to improve a feature will be rewarding to the community

• Offer a mechanism to provide feedback

Next Steps

• We should offer an e-mail on the Wiki where we define the work plan items

• We should break them down on to tasks

• In four weeks, assign the specific tasks, and define a timeline for each of these

Scheduling the Next Call

• Next TAC call is scheduled to be held in two weeks

• We are required to provide a work plan, but a draft (which is later adjusted) is acceptable for this

• A Doodle poll will be sent to schedule another call for defining the task list for the Work Plan

• The Work Plan should have a section as a holding place/wishlist for tasks which might not be prioritized for this term

  • EAC-CPF is an example of this (although, after some discussion, it was determined that this might be a higher priority)

The meeting was adjourned at 09:46 PDT/12:47 EDT